Information security is, and always will be, a constant exercise in risk discovery and follow-up risk reduction. No matter the remediations or solutions one may implement, there is always a new vulnerability or public exploit right around the corner. However, there are certainly patterns and attacks that maintain a significant lifetime in internal and external environments. These security issues tend to be more popular attack vectors, and will generally be targeted by attackers first. Therefore, detailed below are the top six security issues nGuard has found during standard penetration tests, the risk involved, as well as how to reduce or eliminate these issues.
NBNS/LLMNR/WPAD Broadcasting Enabled
NetBIOS Name Service (NBNS), Link-Local Multicast Name Resolution (LLMNR), and Web Proxy Auto-Discovery (WPAD) all function by utilizing broadcast for name resolution, specifically the Domain Name Service (DNS) protocol. These broadcasts are generally benign, and quite useful at ensuring a smooth usage of internal resources. However, much like many modern services and protocols, it can be utilized to compromise an internal network. Whenever a ‘victim’ requests a specific resource, and said request contains a typo or mangling of the resource name, the DNS server will reply that the resource could not be found. In order to complete name resolution, the victim will then broadcast to the domain, asking if that particular resource with the typo is known to any other endpoint. Attackers can then respond to this broadcast by claiming to be the resource, then capturing NTMLv1/v2 hashes to be taken offline and cracked.
Remediation: By disabling NBNS/LLMNR/WPAD broadcasts, the threat of hashes being captured is minimized, thus removing a very popular attack method off the threat board.
SMB Signaling Disabled
Server Message Block (SMB) signing allows for SMB traffic to be cryptographically signed for the sake of maintaining integrity. However, in certain configurations, this signing does not take place (or unsigned packets are allowed as a fallback), which can allow a Man in the Middle (MitM) attack to occur. By utilizing legitimate credentials, via impersonation attack for example, an attacker can then authenticate against the victim machine and gain full remote code execution (RCE).
nGuard has lots of experience using this particular attack to gain RCE on multiple host types, from workstations, to physical security control, to domain controllers. Additionally, by combining this attack with LSA dumping (below), an attacker can quickly attain complete control over the domain by either utilizing an existing Domain Administrator account, or even making their own (below). Do note, that while restricting PowerShell command execution on hosts can slow this process down, it is still entirely possible for an attacker to successfully compromise a domain utilizing this method.
Remediation: Avoiding this particular pitfall requires a domain group policy change to always digitally sign communications. Once this group policy is in effect, the ability to have full remote code execution is neutralized.
The Local Security Authority Subsystem Service (LSASS) handles the security policy on Windows hosts; from handling password changes and logons, to writing security logs. LSA can also cache usernames and passwords in the registry that are used to log into a particular system, all in cleartext. That means that an attacker with RCE capabilities can ‘dump’ these credentials by using a valid set of credentials, and then use these dumped credentials to either move laterally along the network, or in certain cases, attain Domain Administrator.
For example, in an internal penetration test, after successfully compromising a host via a well-publicized exploit (resulting in NT AUTHORITY\SYSTEM access), LSA was dumped hoping to attain valid credentials. Instead of getting normal user creds, the dump had found Domain Administrator credentials; which combined with access to a Domain Controller meant full control over the entire internal Windows network.
Remediation: In order to combat this, Microsoft released a patch (KB2871997), which requires some registry changes on applicable endpoints. The good news is that a restart is not required. The bad news is that this registry change requires constant vigilance, as an attacker that attains NT AURHORITY\SYSTEM access can revert the change and lie in wait for a user to log on to dump the cleartext credentials.
Insufficient Logging and Alerting of Suspicious Activity
This may seem like a no-brainer to some, since security logging is paramount. However, sometimes things slip through the cracks. And sometimes these things are self-made Domain Administrator credentials.
As a test of proper logging and alerting of suspicious activity, nGuard engineers will often create a Domain Administrator account (normally ‘nGuardTest). Aside from granting Domain Admin access into an internal network, it also lets us see how quickly (if at all) the account gets detected. Sometimes this happens within a few minutes. Sometimes this happens in a few days. Sometimes, not at all. Any delay in detecting these accounts could be a sign that logging and alerting of this type of activity might be insufficient, and that work needs to be done to improve detection of anomalous activity. In the span of a few hours, a real-life attacker could potentially extract credentials, intellectual property, confidential emails, and proprietary information via a command and control (C2) channel or perform a ransomware attack and hold all your systems and data ransom. Therefore, the difference between detecting this type of activity in a few minutes versus a few hours, can make a massive difference in the potential risk.
Remediation: To combat this, nGuard recommends implementing a Security Information and Event Management (SIEM) solution, or a Managed Services/Security Solution (MSS). By having a central location where all logs and activity can be checked and correlated, it reduces the chance that these suspicious activities can slip through the cracks, and it may mean the difference between finding a rogue Domain Admin account in a few minutes, instead of a few days.
Externally-Facing WordPress Login/Directories
WordPress, when implemented correctly and securely, can be a fantastic way to deliver content to customers. However, in many implementations, this is not the case – which lends to WordPress’ notoriety in information security circles. There are two reasons behind this:
⦁ Misconfigurations: It is very easy to overlook certain security settings in WordPress that would allow for greater security controls. Sometimes even something as benign as an externally-facing login in screen can be used against you.
⦁ Plugins: One would be hard-pressed to find a WordPress implementation that does not use plugins. They can be a powerful tool for many things, ranging from content delivery to Search Engine Optimization (SEO). However, the issue stems from plugins becoming outdated/no longer worked on, or not enforcing plugin security updates. If certain plugins become outdated, they can become a very real attack vector that can lead to compromise.
It isn’t rare to test WordPress applications and find an externally-facing wp-content/uploads directory which has been compromised with some form of malicious content, such as a web shell (that is, an exploit that allows attackers to have command execution on the victim machine through a web application). It is also not rare to see that XMLRPC.php is accessible externally, which can lead to brute-forcing attacks. With the right tools, an attacker can send hundreds of login attempts per single HTTP/HTTPS request, granting them the ability to easily brute-force WordPress logins.
Remediation: Remediation usually involves ensuring that all WordPress implementations and plugins are up to date. If a plugin is no longer actively being developed, considering changing to another plugin with an active developer. Additionally, there are third-party solutions which can harden WordPress implementations, and reduce the potential attack surface.