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?
In order to truly secure your 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 w
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.
2. 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 realised 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 pen-testing 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. Existing in memory makes antivirus whose core function is scanning disk significantly less effective.
When it comes to mitigation; the execution policy restrictions in PowerShell are trivial to bypass.
3. 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, the 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 organisation’s needs, which cuts out much of the work of importing the settings.
4. 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 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 organisations 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 organisation that builds or maintains any internal web applications, think about whether or not that code is being frequently reviewed. 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). Analyses 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.
5. 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 defence 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.
The information contained in this website is for general information purposes only. The information is gathered from Security Newspaper while we endeavour to keep the information up to date and correct, we make no representations or warranties of any kind, express or implied, about the completeness, accuracy, reliability, suitability or availability with respect to the website or the information, products, services, or related graphics contained on the website for any purpose. Any reliance you place on such information is therefore strictly at your own risk.
Through this website, you are able to link to other websites which are not under the control of CSIRT-CY. We have no control over the nature, content and availability of those sites. The inclusion of any links does not necessarily imply a recommendation or endorse the views expressed within them.
Every effort is made to keep the website up and running smoothly. However, CSIRT-CY takes no responsibility for, and will not be liable for, the website being temporarily unavailable due to technical issues beyond our control.