Several polish banks hit by watering hole attack – lessons learnt?

Last days Badcyber.com –informed about ongoing attack on polish banks. According to the news source, it was classic watering hole attack. Attackers were able to infect Polish Financial Supervision Authority (KNF) web service with a malware and further take over several banks’ computers which have visited this web site. The case is initially confirmed by KNF. Also, few of banks have confirmed that their SOCs have seen “network traffic to exotic locations and encrypted executables nobody recognized on some servers” – typical indicators of compromise. You can read whole story here. Can you handle similar risks, when trusted external party is a threat source? Let me share some thoughts and ideas.

What does not work anymore?

• Website whitelisting. Limiting web traffic from workstation only to “trusted” parties will not prevent attacks because you cannot influence security of those sites. As we can see from this and many others “APT” attack cases, nobody is free from mistakes.
• Antivirus as a ultimate defense. It’s a common fact that targeted attack can easily bypass antivirus detection. We have seen this many times and we’ll see more in the future. Nowadays antivirus should be treated only as the protection against common attacks not targeted ones. There is some hope in more advanced detection strategies (expect buzzwords like AI, deep/machine learning, threat intelligence, etc) but those techniques are still not widely evaluated by research community and some say that they will be bypassable too.
• Focus on perimeter security and treating internal sources as trusted. Most of the last attacks against big institutions leveraged the fact that old, mature IT infrastructures have concentrated their defenses on the perimeter (because it’s easier and we have all the tools needed) and assumed that it’s almost impossible to enter internal networks (because internal networks are large and difficult to protect). In most of the cases, if attacker is only able to install malware on one of the internal workstations and take over one of employees’ identity, he can easily find ways to attack other internal systems because they are almost unprotected.

Of course – we should still use above safeguards. They are still effective as basic protection against common threats and could be sufficient for less critical businesses. But for mission critical systems and internet centric businesses, they should not be in the center of our attention anymore.

What could be more effective?

• Zero trust approach. Treat your internal systems (especially user’s workstations) as a potential attack source or even better – build your network and defense strategy treating internal computers same as external ones. Trust boundary should be moved much closer to key resources. Such approach sounds radical but in my opinion it is inevitable, considering current attack landscape. One remark – notice that if you are moving your key systems to the cloud or you are extensively using SaaS applications, then you already have such threat model.
• Focus on protection of internal systems. If you have protected external facing systems, move your focus to internal ones. As you can see from abovementioned example and other “APT” scenarios, your perimeter is not as sharp protection border as one might think anymore.
• Verify security of your internal applications. Same approach should be taken into consideration for internal applications which usually are Achilles’ heel of IT system and probably they are being targeted by the attackers as well. Mostly because app vendors and programmers usually think that “it’s safe because it’s not internet-facing”.
• Identity management for internal users. Leverage power of IDM features that are available in your solutions (e.g. Active Directory). It will be much easier for you to take control of users’ access rights, detect anomalies and take action in case of compromise.
• Honyepots/honeytraps for compromise detection. If you assume that an attacker can act from your internal network, you should be able to detect his presence and movement. It’s fairly easy to build early detection mechanisms such as false resources (services, URLs, application functions, users, files or even data records) that cannot be touched. If they are – it’s clear indicator of compromise. You can build such as detectors by yourself or use ready to deploy solutions such as Canarytokens (free), Canary Tools (paid) or OWASP AppSensor for embedding detection into your applications.
• Be prepared for attack. Don’t expect that you will not be attacked. If you have resources that can be valuable to attackers – sooner or later you will be targeted. If you are following the news you can expect that they will enter your network using one of your workstations. So, be prepared. Act and make security decisions assuming that one of your workstations and employee’s identity can be taken over. This assumption should have major impact on your risk assessments and security action plans. Yes – it’s a big move but sooner or later you have to make it. It’s better to take proactive path and do it by yourself than to be forced by security incident.

If you are using penetration testing as a verification of your efforts, then do internal security testing with access to several workstations and with user rights or even local admin rights as a starting point. This will simulate real conditions of attack being made by means of installing malware on some of your computers as in abovementioned case.

So as general rule of thumb – don’t ask “Are they able to compromise one of my workstations?” but rather “What if they will?”.

Wojciech Dworakowski Managing Partner