Over the past two decades, I’ve noticed an emerging trend in hacking: attacks are becoming more sinister given the fact attacks are increasingly personalized and especially covert. Back in 2002, blatant website defacements and hoax-like viruses were all the rage. But unlike the technical pranksters of yesterday who sought out notoriety, the hackers of today are motivated by financial gain. Their goal is to breach systems of interest prolonged periods of time; all without a trace of detection.
Defenders of security have to step up their game as the tools of today aren’t cutting it. The information technology space simply moves too quickly for traditional tools like SIEM, antivirus, and firewalls to remain effective. While I’m not advocating we decommission these security tools anytime soon, we have to understand that these tools provide what is now a very primitive baseline set of functionality which thwarts common attacks. Hackers are well-aware of these limitations, and are therefore evolving attacks to non-predictable means by employing tactics such as zero-day exploits and social engineering.
Here are just a few attack scenarios that have become incredibly difficult to detect and thwart given the highly-personalized attack vectors.
Spear-phishing for financial gain is a phenomenon that plagues countless enterprises of today. The strike commences with the attacker posing as a legitimate entity, such as a CFO or an established vendor of the company. Through social engineering, the attacker persuades an individual with financial access to wire money to the imposter. This typically takes place over email (and sometimes via phone and snail-mail augmentations for “authenticity”) and doesn’t require malware or network “breach” in the traditional sense. This is why spear-phishing is so hard to detect.
#2 Botnet DDoS Attacks From AWS
Your development team loves to tout they “stood up data center in five minutes,” yet they can’t figure out why their AWS network charges are so high. After weeks of investigation, it becomes apparent that a cluster of EC2 instances were compromised and promptly used by hackers for DDoS attacks. How could you have used existing investment in security tooling to scrutinize Amazon’s network traffic?
#3 Typosquatter Domains
Imagine you’re a service provider named “Acme Loan House” and your call center complaint department realizes a sudden increase in customer complaints around fraudulent transfers. Upon investigation, you realize hackers are using typosquatting domains to lure your customers into credential theft traps. These similar domains are hard to spot with the human eye. Hackers cleverly replace the letter ‘o’ with zero, and the letter ‘L’ with an uppercase ‘i’ to fool customers with impostor domains: AcmeL0anHouse.com, AcmeIoanHouse.com. How could you have monitored the web for such impostors?
Fighting Fire with Fire
If hackers are going to personalize their attacks, then we increase the intelligence of our defense systems by incorporating corresponding “counter-attack logic.”
In each scenario above, a very small amount of custom code could have been implemented to augment existing security tooling. The key is not to throw away existing tooling, but to weave-in custom logic to bolster its current capabilities.
For the spear phishing scenario, a relatively simple script embedded in the existing mail transfer agent (MTA) could break apart the source address and reconcile the “friendly name” portion of the “FROM:” address and quickly determine if the email is simple spoof. Additional message parsing for terms like “transfer” and “wire” are also possible.
With respect to the AWS scenario, a couple web service calls and some basic scripting could have saved the day by automating the shipping of VPC flow logs to CloudWatch, S3, and your existing logging solution, which likely would have caught the sudden increase in network traffic.
Finally, the typosquatter domains could have been monitored with a very simple Python (or other language) script that examines your brand domain names (AcmeLoanHouse.com) and compares against fuzzy matching that alerts when an impostor domain emerges.
Developers to the Rescue
There are countless ways to achieve the aforementioned countermeasures. From hiring security consultants, to onboarding full-time employees, to sourcing an eclectic mix of outsourced service providers; each of whom provides specific functionality. Frankly, how you go about sourcing the talent is not as important as focusing on what to look for: application developers with an information security background.
Standard tooling and “conventional” security skills are no longer sufficient in combating these modern attacks.Therefore the goal is to build very small and selective modules of custom logic to thwart these highly personalized attacks. In order to do so, you need someone who understands the custom attack vector, and how to breath new life into existing security tooling investments with an “intelligence upgrade.” This requires true software engineering expertise; something not commonly found in all security operations teams of today.