Script Kiddies 4.0

Penetration tests try to find and legally exploit weaknesses in a system's security, so admins can manage their computer systems more securely. Security problems can be identified by using an automated tool, a manual method, or a combination of the two. In this environment, PowerShell can deliver excellent results with its modules for penetration testing and exploits.

Some PowerShell extensions expand the command set or provide more secure alternatives for standard procedures, such as SSH as an alternative to Windows Remote Management (WinRM) remote maintenance. Even malware scanners are implemented as PowerShell components.

Testing Windows Systems

The PowerShell PowerSploit [1] module, developed for penetration testers and reverse engineers, is used for penetration tests and as a vulnerability scanner. PowerShell is the ideal post-exploitation utility for Windows because of its ability to perform a wide range of administrative and low-level tasks without leaving traces on the hard drive. PowerShell scripts run completely in memory and are remote-enabled. The module supports IT managers in the following tasks:

• Code execution: Execution of low-level code and code injection.
• Script modification: Modifying or preparing scripts for execution on a compromised machine.
• Reverse engineering with appropriate tools.
• Filtering: Access to sensitive data from a compromised machine.
• Chaos: Destructive instructions.
• Recon: Support in the reconnaissance phase of a penetration test.

Local installation with install modules might activate your virus scanner, so you should unblock any ZIP files you download from the GitHub repository; otherwise loading additional modules fails (Figure 1).

By combining applications like AppLocker, rigid access restrictions, and PowerSploit cmdlets, you can find an optimal configuration that makes it possible to strike a balance between functionality and security. The field of application is therefore primarily simulated attacks on remote computers.

The Invoke-Shellcode function injects executable statements into the context of running applications by selecting the host process with the process ID. An assignment of processes and process IDs is easy to implement with:

> Get-Process | Select-Object -Property name, ID

PowerSploit expects a list of bytes in the form 0xXX,0xXX,0xXX,0xXX. The Backtrack toolset is helpful for generating the correct format:

> msfpayload windows/exec CMD="cmd /k calc" EXITFUNC=thread C | sed '1,6d;s/[";]//g;s/\\/,0/g' | tr -d '\n' | cut -c2-

This command string correctly prepares the -Shellcode parameter value. When passed to -Shellcode without specifying a process ID, the Invoke-Shellcode cmdlet starts the machine in the process space of the current PowerShell.

Finding Unknown Shares

Network shares that are not inventoried, whose permissions structure is obsolete and point to users who are no longer active in the company, are a security problem. Documenting the existing shares is a necessary first step toward cleaning up the existing structure and a conceptual new beginning.

The Invoke ShareFinder function from PowerSploit is very helpful for this objective. It uses the Get-NetDomain cmdlet to find the local domain name for a host and asks the domain for all active hosts (with the Get-NetComputer cmdlet). Each server lists active shares when queried by the Get-NetShare cmdlet.

Secure Passwords

PowerSploit's Invoke-Mimikatz exploit function lets you extract plain text credentials from memory, password hashes from local SAM/NTDS.dit databases, advanced Kerberos features, and more. The Mimikatz codebase in PowerSploit is slightly modified compared with the original; it runs only in memory and leaves no traces on the hard drive.

Manipulating DLLs

The complete module is not always necessary; sometimes a single test is sufficient. For example, if you want to manipulate a DLL, the corresponding function is available online [2] as source code. The attack stored in this function is aimed at executing a DLL file in the process space of another process. A DLL is a collection of code or data that can be used by multiple applications (or other libraries and modules). Thus, any executable malware can be hidden in such a file. For a security test, first save the file and load it into the scope of the console by means of sourcing:

. .\invoke- DllInjection.ps1

The function with the same name is then available. Now you need malware in the form of a DLL file and a process, including the process ID:

> Start-Process c:\windows\system32\notepad.exe -WindowStyle Hidden; get-Process -Name notepad; Invoke-DllInjection -ProcessID 251 -Dll C:\temp\test.dll

Forensic Analysis After Attacks

If a system – or the entire network of a company – has been compromised, the cause of the attack and the underlying vulnerability must be identified. PowerShell is supported by the PowerForensics module [3], which helps security officers and administrators analyze digital media and computer systems.

The PowerForensics module is divided into the following sections:

• Hard drive tools: Accessing the master boot sector and analyzing the partition table
• Filesystem (FAT, NTFS)
• Windows registry
• Traces of users in the operating system

The search for artifacts in the operating system is the central feature in the tool. For example, you can use the Get-ForensicWindowsSearchHistory cmdlet to find and process entries in the Windows search. The return type is a separate object with User and Searchstring interfaces. Both can be filtered using wildcards and regular expressions. The Get-ForensicTypedUrl cmdlet lets you access the browser.

In general, the PowerForensics module suffers a little from poor performance. When it comes to PowerShell modules, the value for the user is also highly dependent on the documentation. With no comment-based help for the exported functions, using them is unnecessarily difficult.

Conclusions

PowerShell modules provide a flexible way to provision functionality temporarily. When the console is closed, all extensions not loaded by profiles disappear from memory. Because actions and scripts can also remain on storage media without consequences, the "penetration tests" are very realistic. Problems in the security architecture, including non-configured remote maintenance, are then easily detected.