.png)
It should come as no surprise that Microsoft has been the dominating factor in the desktop and laptop market. In 2015, Microsoft estimated that Windows 10 alone would reach 1 billion users in three years time.
While the exact number of Windows users is difficult to pin down, the fact of the matter is that whether it’s half a billion or a figure that’s closer to 10% of the world population, most PCs are Windows products. This means that Windows is going to be a major focus by threat actors.
The scope of this article is to examine some of the tools and vulnerabilities threat actors are using to exploit into Windows operating systems, and preventative measures to help minimize the attack surface on such devices.
Phase 1: Malicious Authentication Requests 101
Open-Source Intelligence (OSINT) tools play a vital role in using public resources for information gathering. You would be shocked at the sensitive information a person might find simply using legally obtained channels.
From a network security analyst’s perspective, scans can oftentimes exhibit the same TCP/IP behaviors as malware, denial of service, and brute force attacks. Repeated TCP authentication requests, regardless of the sender’s purpose or motive can appear suspicious.
Since software-based IP, port, and vulnerability scanners can be extremely obtuse on both the attacker’s network and that of their target, free online services that perform these functions for professional and educational purposes are often abused.
For example, an attacker can use the Shodan search engine to passively scan a large IP netblock for machines running some version of Windows Server with an open Remote Desktop Protocol (RPD) port facing the internet.
By using certain filters to narrow down searches for isolating a particular criterion, almost anything public-facing on the internet can be uncovered with Shodan. It may provide screen captures of the Windows login screens, with additional information such as usernames and workgroups along with a variety of other information that is useful during OSINT reconnaissance.
This type of attack depends on two conditions to be met in order for it to be successful. The first condition depends on whether the Windows device is configured to allow multiple erroneous login attempts and if the user’s password is common enough that it could be found in an attacker’s dictionary file.
Assuming the reader has read enough emphasis here and elsewhere about not choosing rudimentary passwords, we can move on. The point is, without assigning a limit to erroneous login requests in conjunction with using awful passwords, the device is susceptible to password attacks.
Phase 2: Rage Against The Protocols
Linux command-line interfaces (CLIs) like Crowbar, Hydra, and Metasploit framework each provide proficient options that can aid a threat actor to leverage an attack. Each one of these tools has legitimate usage. But like with anything placed in the wrong hands, the same can be weaponized for gaining illegitimate authentication, and not only with RDPs, but SSH, FTP, HTTP, HTTPS, SMB, and many more.
Configuring the Account Lockout Policy in your Local Group Policy Editor is a vital defense by setting a limit to erroneous login attempts, not only on the User login screen but on all desktop services and network protocols that require authentication.
This is the first step to preventing brute force attacks. From the Policy Editor, you can set a limit to the number of erroneous login attempts simply by configuring the Account lockout threshold.
Relying on port forwarding really isn’t a solution, because hackers can still discover the forwarded port, and obtain a fingerprint of the service it is attempting to mask. If they are still able to do this, and launch a password cracking attack at all, that’s because your router and Intrusion Detection System (IDS) rules are misconfigured by allowing unnecessary incoming TCP/IP connections from untrusted devices across the internet.
Metasploit framework also has RDP checking and scanning functions under
msf6 > use auxiliary/scanner/rdp/rdp_scanner. Obviously, it’s armed to be able to scan, detect, and exploit virtually any network protocol.
However, it is quite proficient at finding and exploiting Windows devices that are vulnerable to BlueKeep RCE (CVE-2019-0708), as well as EternalBlue (CVE-2019-0708) remote code execution exploits. Both focus on exploiting unpatched and exposed Windows devices with an enabled RDP.
While covering which versions of the Windows OS are vulnerable would amount to an unnecessarily lengthy word salad, a viable defense against these exploits is simply to maintain Windows updates, because updates focus on protecting users from the latest security issues that target the operating system.
A Hackers’ Favorite: PowerShell Exploits
The crazy thing about PowerShell exploits is they exist as fileless malware. This means they do not depend on or utilize traditional malicious files or executables in order to gain access to a vulnerable system, but rather, function as remote code execution that is injected into the victim’s computer memory (RAM) and deployed through different legitimate system processes like PowerShell.
Additionally, it has no native security features to fortify the operating system against PowerShell being abused, except for a feature called Execution Policies. But anyone with access to the PowerShell can alter or circumvent these policies without any resistance.
Because PowerShell can launch commands directly from the computer’s RAM while functioning apart from any files or data saved to disk, it leaves no digital fingerprints behind on disk. From a threat actor’s standpoint, PowerShell is the most ideal attack vector for flying under the radar.
The disturbing fact is that PowerShell exploits are able to evade IDS detection, as well as signature-based antivirus scanners.
No digital breadcrumbs to follow.
Symantec described the attack as being able to avoid security products such as the Symantec Endpoint Protection software suite, saying:
“Running a full system scan with SEP will not identify any malware. PowerShell is a legitimate tool: SEP’s AntiVirus component will not stop it. Even if a SEP full system scan turns up no malware, malicious code might be running in memory via PowerShell.”
Symantec offered a variety of defensive countermeasures against the attack, but they are arguably unreliable for prevention, relying heavily on behavioral analytics, maintaining PowerShell with the latest updates, and the hope for improvement of PowerShell logging, monitoring, and forensic analysis of events. This means there’s going to be a lot of post-intrusion clean-up, and less actual, prevention. Symantec said:
“With the evidence, we have shown of a rising tide of threats leveraging PowerShell, we recommend bolstering defenses by upgrading to the latest version of PowerShell and enabling extended logging features. Additionally, make sure that PowerShell is considered in your attack scenarios and that the corresponding log files are monitored.”
Latest In Microsoft Bugs: Exploitable OEM Flaw
Security researchers at Eclypsium recently discovered a new bug that affects the Windows OS from Windows 8 and onward, which, when exploited, could allow a threat actor to install and execute a rootkit during the boot process, granting them kernel privileges on affected devices.
The vulnerability disrupts the Microsoft Windows Platform Binary Table (WPBT), an Advanced Configuration and Power Interface (ACPI) table that was first implemented in the Windows 8 OS which allows manufacturers to embed binaries into the UEFI boot firmware, which gets stored in the WPBT.
When Windows boots up, it first queries the UEFI firmware to look for these binaries, copies them to the operating system, and launches them, no questions asked.
However, the security issue exists in the fact that WPBT allows a signed binary with a null or expired certificate to continue to bypass integrity checking functions. This allows a threat actor to sign their own maliciously crafted binaries bearing existing expired certificates for the purpose of running arbitrary scripts with kernel privileges when the device is booted.
You can ask yourself, “What’s the purpose of that?” It allows independent software vendors and equipment manufacturers to sign portable persistent executables directly into the firmware that can execute during the boot process.
One practical way to utilize WPBT in a good way would be if anti-theft software was installed, commonly called a LoJack, which could be triggered during the boot process to track the stolen device.
Eclypsium equated the threat vector as “motherboard-level flaws” saying:
"These flaws make every Windows system vulnerable to easily-crafted attacks that install fraudulent vendor-specific tables."
They explained how the tables can be exploited by threat actors regardless of whether they have physical access, remote access, or by infecting the supply chain of manufacturers.
As a preliminary, Microsoft encourages users to utilize a Windows Defender Application Control (WDAC) policy in order to create hardened restrictions over what binaries can be allowed to run on Windows devices.
Sometimes it can feel overwhelming knowing that there is so much responsibility when it comes to the pressure of covering every conceivable base. Take it one step at a time by choosing unique passwords and configuring limits for failed password attempts. Be sure routers are configured to only allow inbound TCP/IP requests from trusted sources, don't panic, and be ready to adapt when things change.
An article by
Jesse McGraw
Edited by
Ana Alexandre
Like this content? Subscribe to our newsletter to get weekly cybersecurity insights and top news - straight to your mailbox!
Comments