IT Security Survey in the UK – 75% Hacked in Past Year

Cyren teamed with Osterman Research to do extensive interviews of IT and security professionals at over 100 small and mid-sized enterprises (SME) in the United Kingdom last month, and the resulting report, IT Security in the UK: 2017 Business Survey, is now available for free download. A summary overview of the report was the subject of a webinar available here

There are a lot of surveys and reports and white papers circulating which inevitably focus on security issues at the largest enterprises, but the amount of information available on the security posture, problems and priorities of small- and mid-sized enterprises and governmental organisations, defined for the purposes of this survey as organisations with 100-5000 employees, is noticeably thin, and so this report fills part of that vacuum of available research.

Survey responses were further broken out and compared according to three SME employee size ranges, specifically 100-1000 employees, 1001-2500 employees, and 2501-5000.

The survey report is an opportunity for any IT or security professional at a mid-market company in the UK to benchmark themselves against the responses from their peers.

2017 UK Osterman Research Survey

Some survey “takeaways” include:

  • Security problems are rampant – 75% of organizations surveyed reported a security breach or infection in the last 12 months, rising to 85% for businesses with 1000 or fewer employees. This number is consistent with the finding from a similar U.S. survey done by Osterman and Cyren last June, where the corresponding number was 71%.
  • The threats rated of greatest concern are data breaches, ransomware and targeted attacks/zero-day exploits. Ransomware infections were reported at twice the rate at organizations with fewer than 1,000 employees, when compared to organizations with 2,500-5,000 employees, 6 percent vs. 3 percent, respectively.
  • The greatest security gaps, where IT managers’ level of concern most outstrips their evaluation of their security capabilities, are in dealing with targeted/zero-day attacks, the threat of data breaches, botnet activity, and malicious activity from insiders.
  • Only 19% say their web security is inspecting SSL traffic for threats.
  • IT managers are far more concerned about the costs of infection than the cost of protection. The initial cost of web or email security solutions or their total lifecycle cost were ranked much lower as decision criteria than features like ease of administration, visibility, and advanced security protection (the top three categories).
  • IT managers are far more concerned with stopping malware than controlling employee web behavior, with the exception of preventing access to pornography from business networks. “Shadow IT” is a moderate concern for larger companies, but a low priority for those with 1,000 employees or less, with only 9% considering it of concern.
  • The largest organizations surveyed, with 2,500-5,000 employees, are currently rating application control as the most important capability in evaluating new solutions, with 73% rating it extremely important. This compares to just 43 and 41 percent of organizations in the two smaller employee size categories.
  • Data Loss Prevention is highly utilized in the UK, ranking as the second-most-deployed capability for both web security (64%) and email security (62%), among the capabilities evaluated.
  • Less than 25% say they protect company-owned or BYOD mobile devices, and less than 30% of remote offices and Guest Wi-Fi networks have gateway security. The vast majority of organizations rely on endpoint protection for traveling employees’ laptops and to protect use of the web at remote offices.

Feel free to reach out to the Cyren team with any questions.

I was checking my bank account online when I got alarmed by my browser prompting me that the site’s certificate was invalid as shown below:

tl_files/assets_cyren/images/blog/bank cust pic1.png

Figure 1: Invalid website certificate prompt

I usually don’t get this prompt since I regularly check my accounts online, so out of concern and curiosity, I clicked on the “Continue to this website” link and started an investigation.

Being taken to a legit-looking but unfamiliar login page as shown below, I called up my friend from another city to give me a screenshot of the bank’s real web site.

Figure 2: Fake redirection page

tl_files/assets_cyren/images/blog/fig3.png

Figure 3: Fake login page

Definitely not the same as the legitimate login page screenshot sent by my colleague.

tl_files/assets_cyren/images/blog/fig 4.png

Figure 4: Legitimate login page

Moving on, I tried to enter dummy credentials of my own into this fake login page and see how it would interact.

tl_files/assets_cyren/images/blog/fig 5.png

Figure 5: Dummy credentials for fake login page

Low and behold, the web page accepts the credentials I entered and guides me through the following pages:

tl_files/assets_cyren/images/blog/figure 6.png

Figure 6: Card expiry date?

tl_files/assets_cyren/images/blog/figure 7.png

Figure 7: And even OTP!

As I have entered dummy credentials in the login page, I also entered dummy values in the above pages only to be taken to a page saying that the site is undergoing maintenance.

tl_files/assets_cyren/images/blog/fig 8.png

Figure 8: Site maintenance page

Going deeper into my investigation, I opened the page properties to check the invalid certificate, which definitely seems invalid seeing the Issued to and by fields as shown below.

tl_files/assets_cyren/images/blog/fig 9.png

Figure 9: Invalid certificate details

We’re definitely onto something here, so let’s pull out our guns and get ourselves busy. Doing a route trace on the web site server we get the following results:

tl_files/assets_cyren/images/blog/fig 10.png

Figure 10: Traceroute from Fing

Checking the whois information of the culprit’s server IP we get the following info.

tl_files/assets_cyren/images/blog/fig 11.png

Figure 11: WhoIs Info Details

I know for a fact that I didn’t receive any spear-phishing emails nor got my devices infected by banking malware so how did this phishing attack happen?

To verify if my devices are compromised or not, I disconnect from my DSL network and try to access the bank’s website via mobile data connection, and as I suspected, the redirection to the fraudulent page did not reoccur. Running a route trace gives me the following results:

tl_files/assets_cyren/images/blog/fig 12.png

Figure 12: Traceroute from Fing

I reconnect to my DSL network to check if the fraudulent page, which still does show up using in my DSL network. So I call up my ISP to report this incident, got issued a support case ticket and ensured that they will look into it immediately. Also contacted the bank’s call center to report the incident just to give them a head’s up.

Thinking back to what I have done so far, I realized one thing. Why did the URL resolve to the correct IP when I connected to my mobile data connection?

Let’s go back to our first question, how did the phishing attack happen? If the attack was not delivered via email nor was delivered through malware, the attack reoccurs only in my DSL network and route trace to the bank’s domain server resolves to different IPs can mean that there could be a problem with my DNS settings. This brings us to think about the possibility of DNS poisoning as the root of the attack.

DNS spoofing (or DNS cache poisoning) is a computer hacking attack, whereby data is introduced into a Domain Name System (DNS) name server’s cache database, causing the name server to return an incorrect IP address, diverting traffic to another computer (often the attacker’s).

(From Wikipedia) Normally, a networked computer uses a DNS server provided by the computer user’s organization or an Internet service provider (ISP). DNS servers are generally deployed in an organization’s network to improve resolution response performance by caching previously obtained query results. Poisoning attacks on a single DNS server can affect the users serviced directly by the compromised server or indirectly by its downstream server(s) if applicable.

To perform a cache poisoning attack, the attacker exploits a flaw in the DNS software. If the server does not correctly validate DNS responses to ensure that they are from an authoritative source (for example by using DNSSEC) the server will end up caching the incorrect entries locally and serve them to other users that make the same request.”

So how do we resolve the issue while we wait for the ISP to solve the issue on their end?

Well, one thing we can do is modify our network configuration and change the DNS server settings. For this case, I tried to use OpenDNS servers. Voila! The phishing page is gone and my online banking access is back to normal.

Malicious attackers and cybercriminals out there have a lot of tricks up their sleeves but it does not mean that we don’t have tricks of our own. So you don’t fall as victims to these types of attacks, it would be very helpful for you to be vigilant enough to read through all of the warnings that you may see when you are doing online transactions. Make your that you are only allowing valid and verified web site certificates in your browsers. Banking web sites will surely have authentication policies in place which we can put also into use as to what I have done by using dummy credentials first. You can even max out the password retry limit and then just request to change your password later on to ensure that you are accessing the valid banking website.

You can verify the validity of suspicious URL’s or IPs using our reputations services such as CYREN’s IP reputation and URL category checker.

Lastly, we always recommend users to practice safe browsing habits to thwart off attacks like phishing and scams.