Pulling the plug on the Internet is often jokingly referred to as the best solution for network security. All kidding aside, anything you can do to make it harder for the bad guys to gain access to your network can have a positive impact on your overall security posture. That begs the question: with so many cyber security threats and attack methods to worry about – and so many hardware and software solutions to consider – where should you focus?
To get a foothold in a modern enterprise network, attackers require three critical elements: access, code execution, and accounts. In today’s blog, we’ll take a closer look at how cyber criminals can exploit each of these, and how you can thwart them.
Access: Phishing is Still a Threat Actor’s Best Friend
Adversaries can’t succeed without first being able to get to your data somehow, some way. So when we perform penetration tests, our team uses remote access and insider approaches to get inside the network to find out if anything is “exploitable.”
This ‘yes’ or ‘no’ question measures one thing – the client’s ability to patch Internet-accessible systems. This is an essential element for security and data loss prevention, especially since poor patch management leads to a near 100 percent likelihood of being compromised. A perfectly patched network is only part of the battle, though. As a pen tester, what do I do when faced with a real world environment where I cannot remotely exploit any vulnerabilities? Phish!
Phishing is the culprit behind many infamous hacks and data breaches, and continues to be the most common method for threat actors to get network access. Why is that? Let’s run the numbers. Anyone with basic HTML coding skills can set up an email account, register a domain name for $10 a year, and get a cloud-hosted server for just pennies an hour. On the black market, exploit code can cost anywhere from a few thousand dollars for a known vulnerability to tens of thousands of dollars for a zero-day exploit. If you wanted access to a network, would you spend $30 to set up a phishing campaign, or thousands of dollars for exploit code?
Looking at cost alone, it’s easy to see why phishing will remain a viable tactic for bad actors for the foreseeable future. It also illustrates why you should look at your email security to prevent phishing attempts from getting through to end users in the first place, and schedule regular phishing testing and awareness training for employees.
Code Execution: How Monitoring for New Server Processes Can Help
Before a bad actor can search for things to steal or compromise – like valuable customer data or your financial records – the first thing they need is an open communication channel with your network. Code execution is at the heart of this, and remote exploitation code execution is rather simple, especially if there’s lax web security and application security. Whatever back-end code your server or application is running is the same code that will be executed. Simple enough, right? It should be, but I’ve found most organizations aren’t capable of or don’t bother with detecting when a new process starts on their servers. If organizations understood code execution better, they’d spend more effort monitoring for new processes.
I’ll use a common web application language like Java to illustrate this. Web application code enables websites to work. Feature-rich sites have code that helps you see how much things cost, for example, and allows you to search for products and sign up for various services. The first thing attackers want to know is the language powering your web application.
Humans need to communicate through a common language to understand each other. Web applications are similar. In order for an attacker to insert code that your web application can accept and run, it has to be in a language that app understands. This is where network defenders should pay attention. Security and IT professionals often want to block all web application code execution, but that’s not always entirely possible. Sometimes departments require access to a web application because they can’t migrate to a new one just yet, for example. In those cases, you should turn from prevention to detection.
However, many people don’t fully understand their web application languages and what processes are associated with them. When attackers exploit a web application, that application must start a new process before an attacker can get full execution rights over it. That new process will be the same type as the web application language. For example, let’s say that an attacker exploits a Java-based web application. What new process will be started? That’s right - Java! If you know a web application only uses three Java processes under normal operating conditions, and suddenly a fourth Java process is running, you should investigate the new process. Sounds quite simple, but I rarely see this in practice. You don’t need to monitor for every code type, just the most logical ones.
Phishing code execution is unique, and it’s an element of pen testing that not nearly enough organizations use to their advantage. Most often, organizations just want to know how many people clicked on the phishing link in the test campaign. That basic metric provides data that can help you see how effective your security training program is, and address any employees who are repeat offenders, perhaps, but an adversary doesn’t care. They just want to know if the code they send will be successfully executed on your systems.
Here’s where phishing gets more complicated. If I’m running a phishing campaign, I need to have a payload that works not just on your operating system (i.e., Windows, Mac OS X, Red Hat), but the specific version of your operating system. Most operating systems use displays that show end users what’s happening when they go to install and launch a new executable. This means they’re presented with pop-up windows. Pen testers can help you understand the different types of code in your environment that can be exploited through phishing attacks, as well as the average number of steps required for each payload to execute. If a user clicks ‘cancel’ on step 2 of 3, then the code won’t be executed, thus preventing access. Depending on the size of your organization and your business, another option may be to lock down the ability to download and run new applications or executables from the Internet or email to only those users with certain rights or privilege levels.
Accounts: Unmanaged Group Architecture is a Big Advantage for Bad Guys
Okay, so the adversaries got the code to execute and established a foothold in your network. Success for the attackers, right? Not so fast.
In our pen testing engagements, I’ve found networks where we get initial access, but with proper Identity and Access Management practices in place, we’re prevented from moving laterally. Those networks are, defensively speaking, awesome! However, most of the time we find the other kind of networks: those without strong account management practices.
The first thing I try to learn once I’m in a network is what privileges I have. Am I an ordinary user who can’t do anything on the system, or am I an administrative user? From the immediate system, I branch out. I also want to know whether the account I have provides administrator access to other systems. Believe it or not, but I’ve experienced many networks where a person is not an administrator on their own system but has administrator access on others!
In one instance, a single misconfigured system allowed every user on the network privileged access. Once we laterally moved there, we grabbed the passwords of every privileged user. This is fairly trivial for an experienced pen tester or bad actor once they get initial access. As illustrated, account permissions and setup are critical.
Penetration tests can help you understand whether or not you have a problem here, and how this may impact your security policies. If you’ve never included account management within the scope of your penetration tests, I assure you it’ll be eye-opening. While you’re at it, consider including wireless networks and mobile devices to look for any gaps there as well.
Hopefully this blog shed some light on how compromises occur and help you better respond to threats. The key takeaways are that most threat actors don’t focus on exotic exploits, instead relying on tried and true tactics like phishing. The second point is that a determined adversary will keep trying to compromise your organization until they finally break into it. Those last six words are powerful – until they finally break into it. You need to be prepared by ensuring you can detect and respond to new processes on Internet-accessible servers and web applications. You should also implement policies and tools like IAM to prevent accounts from being used to compromise your entire network if someone does get into one of them.
Get our eGuide
Hacker Secrets Revealed: 5 Lessons Learned from Security Assessments