Don’t Forget Your Internal Pen Tests

Many of the requests that we receive are limited in scope to Internet facing assets.  A true understanding of the threats facing your networks requires a complete evaluation of all possible threat vectors. So what kinds of vulnerabilities does an internal test find that an external would miss? Schellman was recently engaged to perform an external and internal penetration test for a software development firm. The external test revealed very little about the company. Strong firewall rules opened only the most necessary of ports (80 and 443) to the Internet. All external facing servers were well patched, running modern operating systems and lacked any exploitable vulnerability. However, the internal assessment told a completely different story. We began the test with no credentials on a “rouge device” that was placed on the internal network. A database server running an automation tool exposed a scripting console that allowed unauthenticated commands to be run on the underlying OS. A VBS script that downloaded an executable was run followed by another VBS script that executed the shell program.  With this foothold, we impersonated the token of a database administrator who also happened to be a Domain Administrator. A few commands later, we’d taken over the domain. If our client had only engaged us for an external test, none of this would’ve been found.

Home Security (the relatable example)

David recently purchased a new house and is concerned about security. He reads online about the many measures he could take to protect his home and the risks of failing to do so. First up is the low hanging fruit. He installs new locks on all exterior doors and even replaces the front door that had panes of glass that could have been easily broken (and manages to accidently lock his wife out after forgetting to give her the new key). Next he plants imposing, thorn filled bushes underneath the windows to deter passersby from taking a peak inside. Finally, after talking to a sales representative at his local alarm company, has them install a top-of-the-line security system. “Well that was easy”, David thinks to himself.

The next day he arrives home from work to find the garage door standing wide open and realizes all his precautions are for naught if his son forgets to close the door after retrieving his bicycle. He begins considering all the other scenarios that could leave his home vulnerable to intruders. Did the contractor who installed his new granite countertop make any copies of the key? Was the thirty second conversation with his kids about making sure they lock the door when they leave the house enough?  That night at dinner he reminds his son about closing the door and leaves it at that. Fast forward to three weeks later. While on a family vacation a few states away, David receives a call from the police. His house has been broken into. He later learns the thieves had entered through the front door that had been left unlocked by the dog sitter, stole the valuables, and walked out the front door.

IT departments, as a rule, get the short end of the stick. Many IT managers fight a constant battle against a wide array of problems (often with limited resources). They have to keep the systems running, users happy, and everything secure. Often times keeping the users happy and the company’s systems secure is a delicate balance of usability and security. After locking down client workstations, implementing a well thought out patch plan and installing that shiny new proxy how do you know if any of those measures are actually going to prevent a breach? The answer is testing, thorough testing. Unfortunately, many times those “tests” are woefully inadequate. Whether performed internally by company staff who may not have the expertise needed or by a third party auditor who’s been selected based on pricing and not on the quality of work, it’s easy for these tests to miss glaring vulnerabilities. 

Network Security (the corporate example)

Many organizations adopt security strategies similar to David. Rebecca is a CIO whose read story after story of data breaches and wants to avoid seeing her company in those headlines. After doing some research and consulting with her peers she creates a three-month plan to better secure the companies systems against intrusion. Expensive firewalls and other security appliances are installed after a vendor promises these devices will use “propriety, military-grade algorithms” to detect and shut down hackers that are trying to break into the company’s network. A new “security training” program is rolled out to make sure users are aware of the threats facing their network. Finally, a two-factor authentication requirement is put into place without properly training all employees on how to set it up, causing a week of downtime while IT fields requests from users that can’t log in. After reviewing three months of hard work by her IT team, she’s satisfied that their company won’t be featured in “Krebs on Security” any time soon. They do have one scare, an employee named Katie ran a well know piece of ransomware after being tricked by a phishing email, but the infection was quickly contained by the system’s antivirus and no real damage done. The employee is required to review the security training materials but no further action is taken.

This incident prompts Rebecca to hire a third party to conduct an external “penetration test” of their systems. After reviewing the deliverable she’s disappointed by the lack of detail, but pleased that test revealed no vulnerabilities. Not a week passes before she receives a call from a frantic IT manager. While performing some maintenance on one of their web servers he discovered a large amount of company data being staged for exfiltration. Rebecca was stunned, how could this happen? In the aftermath of the breach it was discovered that Katie had not been the only target of phishing emails. An accountant named Dave had also received a phishing email. This one however contained an Excel spreadsheet embedded with a malicious macro. Antivirus didn’t detect anything amiss as this code was designed to appear innocuous to an antiviral scanning engine. Because the finance department ran a piece of legacy software that required excessive privileges, the attackers easily took complete control of Dave’s workstation. The attackers quickly expanded their foothold on Dave’s system and moved through the network with ease and within no time had found the databases holding valuable customer data. Rebecca had put so much effort and focus into the company’s external defenses she’d paid little attention to internal security measures.

The example scenario laid out is just that, an example. However numerous companies have had their systems compromised in very similar manners. Many companies adopt a “hard shell, soft center” security strategy. 

• The Office of Personal Management hack was conducted by attackers using valid credentials obtained from a third party contractor.
• Target’s POS systems were infected with malware in 2013 it was determined malware had been placed on an internal file server after a third party contractor had their credentials stolen via a phishing attack. A Verizon report on the aftermath found “no controls limiting their access to any system, including devices within stores such as point of sale (POS) registers and servers.”
• The Sony Entertainment hack in late 2014 was so destructive because the attackers were able to install their malware on such a wide swath of computers and weren’t detected until the attackers launched their attack.

All of these attacks have one theme in common, once inside the attackers weren’t discovered for months or even years and the reason for this was inadequate internal security controls.

I’ll leave you with a short list of examples that would be found during an internal penetration test that would would almost certainly be missed by an external test. Anyone of these findings (or a combination thereof) could lead to a complete domain compromise.

• Man-In-The-Middle attacks
• Anti-virus evasion
• Privilege escalation
• Open shares with sensitive information
• Intranet sites with poor security