Technology is pulsing all around you, and in the short amount of time that you are hosted in this network that you must try to understand its inner workings. Fortunately or unfortunately, most network and system administrators are persons of habit. All you have to do is listen for long enough, and more often than not it will yield some of those juicy findings, information security experts say.
Regardless of any discussion beforehand, a penetration test has a competitive feel from both sides. Consulting pentesters want their flag, and administrators want their clean bill of health to show that they are resilient to cyber-attack; something akin to a game of flag football. The difference here is that in flag football, both teams are familiar with the tools used to play the game.
It goes without saying that a pentester’s job is to simulate a legitimate threat to effectively determine your organization’s risk, but how can remediation happen without at least some familiarity? Sun Tzu once said, “If you know neither the enemy nor yourself, you will succumb in every battle.”
In order to truly secure our networks, any administrator with cybersecurity duties will need to not only understand what they themselves have, but also step into the shoes of the opposite side.
This article’s intention is to focus on the ‘why’ and not completely the ‘how’. There are countless videos and tutorials out there to explain how to use the tools, and much more information than can be laid out in one blog post. Additionally, I acknowledge that other testers out there may have an alternate opinion on these tools, and which are the most useful. This list is not conclusive. With that being said, let’s get into the list.
This tool, in the information security expert opinion, makes the absolute top of the list. When an auditor comes in and talks about “least functionality”, this is what comes immediately to mind. If you are a pentester, Responder is likely the first tool you will start running as soon as you get your Linux distro-of-choice connected to the network and kick off the internal penetration test. The tool functions by listening for and poisoning responses from the following protocols:
- Link-Local Multicast Name Resolution (LLMNR)
- NetBIOS Name Service (NBT-NS)
- Web Proxy Auto-Discovery (WPAD)
There is more to Responder, but I will only focus on these three protocols for this article.
NBT-NS is a remnant of the past; a protocol which has been left enabled by Microsoft for legacy/compatibility reasons to allow applications which relied on NetBIOS to operate over TCP/IP networks. LLMNR is a protocol designed similarly to DNS, and relies on multicast and peer-to-peer communications for name resolution. It came from the Vista era, and we all know nothing good came from that time-frame. You probably don’t even use either of these. Attackers know this, and use it to their advantage.
WPAD on the other hand serves a very real and noticeable purpose on the network. Most enterprise networks use a proxy auto-config (PAC) file to control how hosts get out to the Internet, and WPAD makes that relatively easy. The machines broadcast out into the network looking for a WPAD file, and receive the PAC which is given. This is where the poisoning happens.
The information security professionals are aware that most protocols which rely on any form of broadcasting and multicasting are ripe for exploitation.
- PowerShell Empire
Before, pentesters typically relied on Command and Control (C2) infrastructure where the agent first had to reside on-disk, which naturally would get uploaded to Virus Total upon public release and be included in the next morning’s antivirus definitions. The time spent evading detection was a seemingly never-ending cat-and-mouse game.
It was as if the collective unconscious of pentesters everywhere came to the realization that the most powerful tool at their disposal was already present on most modern workstations around the world. A framework had to be built, and the Empire team made it so.
The focus on pentesting frameworks and attack tools has undoubtedly shifted towards PowerShell for exploitation and post-exploitation.
It means that some of the security controls you have put in place may be easily bypassed. File-less agents (including malware) can be deployed by PowerShell and exist in memory without ever touching your hard disk or by connecting a USB. A write-up mentioned at the end of this post elaborates much further into this topic. Existing in memory makes antivirus whose core function is scanning disk significantly less effective.
Fortunately, information security researchers say, that the best mitigation here is something you may already have access to , Microsoft’s Applocker. Granted, white listing can take some time to stand up properly and likely requires executive sign-off, but it is the direction endpoint security is heading. This is a good opportunity to get ahead of the curve.
When it comes to mitigation; the execution policy restrictions in PowerShell are trivial to bypass.
- Hashcat with Wordlists
This combo right here is an absolute staple. Cracking hashes and recovering passwords is pretty straightforward of a topic at a high level.
Hashcat is a GPU-focused powerhouse of a hash cracker which supports a huge variety of formats, typically used in conjunction with hashes captured by Responder. In addition to Hashcat, a USB hard drive with several gigs of wordlists is a must. On every pentest that the information security analysts have been on, time had to be allocated appropriately to maximize results, and provide the most value to the client.
Sysadmins, think about your baseline policies and configurations. Typically it is best practice to align with an industry standard, such as the infamous DISA STIG, as closely as possible. Baselines such as DISA STIG support numerous operating systems and software, and contain some key configurations to help you prevent against offline password cracking and replay attacks. This includes enforcing NIST recommended password policies, non-default authentication enhancements, and much more. DISA even does the courtesy of providing you with pre-built Group Policy templates that can be imported and custom-tailored to your organization’s needs, which cuts out much of the work of importing the settings.
- Web Penetration Testing Tools
It is important to note that a web penetration testing tool is not the same as a vulnerability scanner.
Web-focused tools absolutely have scanning capabilities to them, and focus on the application layer of a website versus the service or protocol level. Granted, vulnerability scanners (Nessus, Nexpose, Retina, etc) do have web application scanning capabilities, though I have observed that it is best to keep the two separate.
Many organizations nowadays build in-house web apps, intranet sites, and reporting systems in the form of web applications. Typically that since the site is internal it does not need to be run through the security code review process, and gets published out for all personnel to see and use.
The surface area of most websites leaves a lot of room for play to find something especially compromising. Some of the major issues are:
- Stored Cross-site Scripting (XSS).
- SQL Injection.
- Authentication bypass.
- Directory traversal abuse.
- Unrestricted file upload.
If you administer an organization that builds or maintains any internal web applications, think about whether or not that code is being reviewed frequently. Code reuse becomes an issue where source code is imported from unknown origins, and any security flaws or potentially malicious functions come with it. Furthermore, the “Always Be Shipping” methodology which has overtaken software development as of late puts all of the emphasis on getting functional code despite the fact that flaws may exist.
Acquaint yourself with OWASP, whose entire focus is on secure application development. Get familiar with the development team’s Software Development Lifecycle (SDLC) and see if security testing is a part of it. OWASP has some tips to help you make recommendations.
Understand the two methodologies for testing applications, including:
- Static Application Security Testing (SAST). The application’s source code is available for analysis.
- Dynamic Application Security Testing (DAST). Analyzes the application while in an operational state.
Additionally you will want to take the time to consider your web applications as separate from typical vulnerability scans. Tools (open and closed source) exist out there, including Burp Suite Pro, OWASP Zed Attack Proxy (ZAP), Acunetix, or Trustwave, with scanning functionality that will crawl and simulate attacks against your web applications. Scan your web apps at least quarterly.
- Arpspoof and Wireshark
Arpspoof is a tool that allows you to insert yourself between a target and its gateway, and Wireshark allows you to capture packets from an interface for analysis. You redirect the traffic from an arbitrary target, such as an employee’s workstation during a pentest, and snoop on it.
Likely the first theoretical attack presented to those in cybersecurity, the infamous Man-in-the-Middle (MitM) attack is still effective on modern networks, information security researchers said. Considering most of the world still leans on IPv4 for internal networking, and the way that the Address Resolution Protocol (ARP) has been designed, a traditional MitM attack is still quite relevant.
According to information security researcher, many falsely assume that because communications occur inside their own networks, they are safe from being snooped on by an adversary and therefore do not have to take the performance hit of encrypting all communications in their own subnets. Granted, your network is an enclave of sorts from the wild west of the Internet, and an attacker would first have to get into your network to stand between communications.
Now, let’s assume that a workstation is compromised by an attacker in another country using a RAT equipped with tools that allow a MitM to take place. Alternately, consider the insider threat.
The information security experts said that the best tactics of defense are: encrypt your communications. Never assume communications inside your network are safe just because there is a gateway device separating you from the Internet.
Keep your VLAN segments carefully tailored, and protect your network from unauthenticated devices. Implementing a Network Access Control (NAC) system is something you may want to add to your security roadmap in the near future or implementing 802.1X on your network may be a good idea. Shut down those unused ports, and think about sticky MACs if you are on a budget.
(Visited 73 times, 1 visits today)