Category Archives: Windows

Rainy Day Windows Command Research Results

Sally Vandeven // We have all heard people talk about how much cooler Linux is than Windows, so much easier to use, etc. Well, they are not necessarily wrong… but we have learned that Microsoft has some very interesting gems hiding in plain sight. Seriously, Microsoft seems to be making a concerted effort to add some […]

The post Rainy Day Windows Command Research Results appeared first on Black Hills Information Security.

SharPersist: Windows Persistence Toolkit in C#

Background

PowerShell has been used by the offensive community for several years now but recent advances in the defensive security industry are causing offensive toolkits to migrate from PowerShell to reflective C# to evade modern security products. Some of these advancements include Script Block Logging, Antimalware Scripting Interface (AMSI), and the development of signatures for malicious PowerShell activity by third-party security vendors. Several public C# toolkits such as Seatbelt, SharpUp and SharpView have been released to assist with tasks in various phases of the attack lifecycle. One phase of the attack lifecycle that has been missing a C# toolkit is persistence. This post will talk about a new Windows Persistence Toolkit created by FireEye Mandiant’s Red Team called SharPersist.

Windows Persistence

During a Red Team engagement, a lot of time and effort is spent gaining initial access to an organization, so it is vital that the access is maintained in a reliable manner. Therefore, persistence is a key component in the attack lifecycle, shown in Figure 1.


Figure 1: FireEye Attack Lifecycle Diagram

Once an attacker establishes persistence on a system, the attacker will have continual access to the system after any power loss, reboots, or network interference. This allows an attacker to lay dormant on a network for extended periods of time, whether it be weeks, months, or even years. There are two key components of establishing persistence: the persistence implant and the persistence trigger, shown in Figure 2. The persistence implant is the malicious payload, such as an executable (EXE), HTML Application (HTA), dynamic link library (DLL), or some other form of code execution. The persistence trigger is what will cause the payload to execute, such as a scheduled task or Windows service. There are several known persistence triggers that can be used on Windows, such as Windows services, scheduled tasks, registry, and startup folder, and there continues to be more discovered. For a more thorough list, see the MITRE ATT&CK persistence page.


Figure 2: Persistence equation

SharPersist Overview

SharPersist was created in order to assist with establishing persistence on Windows operating systems using a multitude of different techniques. It is a command line tool written in C# which can be reflectively loaded with Cobalt Strike’s “execute-assembly” functionality or any other framework that supports the reflective loading of .NET assemblies. SharPersist was designed to be modular to allow new persistence techniques to be added in the future. There are also several items related to tradecraft that have been built-in to the tool and its supported persistence techniques, such as file time stomping and running applications minimized or hidden.

SharPersist and all associated usage documentation can be found at the SharPersist FireEye GitHub page.

SharPersist Persistence Techniques

There are several persistence techniques that are supported in SharPersist at the time of this blog post. A full list of these techniques and their required privileges is shown in Figure 3.

Technique

Description

Technique Switch Name (-t)

Admin Privileges Required?

Touches Registry?

Adds/Modifies Files on Disk?

KeePass

Backdoor KeePass configuration file

keepass

No

No

Yes

New Scheduled Task

Creates new scheduled task

schtask

No

No

Yes

New Windows Service

Creates new Windows service

service

Yes

Yes

No

Registry

Registry key/value creation/modification

reg

No

Yes

No

Scheduled Task Backdoor

Backdoors existing scheduled task with additional action

schtaskbackdoor

Yes

No

Yes

Startup Folder

Creates LNK file in user startup folder

startupfolder

No

No

Yes

Tortoise SVN

Creates Tortoise SVN hook script

tortoisesvn

No

Yes

No

Figure 3: Table of supported persistence techniques

SharPersist Examples

On the SharPersist GitHub, there is full documentation on usage and examples for each persistence technique. A few of the techniques will be highlighted below.

Registry Persistence

The first technique that will be highlighted is the registry persistence. A full listing of the supported registry keys in SharPersist is shown in Figure 4.

Registry Key Code (-k)

Registry Key

Registry Value

Admin Privileges Required?

Supports Env Optional Add-On (-o env)?

hklmrun

HKLM\Software\Microsoft\Windows\CurrentVersion\Run

User supplied

Yes

Yes

hklmrunonce

HKLM\Software\Microsoft\Windows\CurrentVersion\RunOnce

User supplied

Yes

Yes

hklmrunonceex

HKLM\Software\Microsoft\Windows\CurrentVersion\RunOnceEx

User supplied

Yes

Yes

userinit

HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon

Userinit

Yes

No

hkcurun

HKCU\Software\Microsoft\Windows\CurrentVersion\Run

User supplied

No

Yes

hkcurunonce

HKCU\Software\Microsoft\Windows\CurrentVersion\RunOnce

User supplied

No

Yes

logonscript

HKCU\Environment

UserInitMprLogonScript

No

No

stickynotes

HKCU\Software\Microsoft\Windows\CurrentVersion\Run

RESTART_STICKY_NOTES

No

No

Figure 4: Supported registry keys table

In the following example, we will be performing a validation of our arguments and then will add registry persistence. Performing a validation before adding the persistence is a best practice, as it will make sure that you have the correct arguments, and other safety checks before actually adding the respective persistence technique. The example shown in Figure 5 creates a registry value named “Test” with the value “cmd.exe /c calc.exe” in the “HKCU\Software\Microsoft\Windows\CurrentVersion\Run” registry key.


Figure 5: Adding registry persistence

Once the persistence needs to be removed, it can be removed using the “-m remove” argument, as shown in Figure 6. We are removing the “Test” registry value that was created previously, and then we are listing all registry values in “HKCU\Software\Microsoft\Windows\CurrentVersion\Run” to validate that it was removed.


Figure 6: Removing registry persistence

Startup Folder Persistence

The second persistence technique that will be highlighted is the startup folder persistence technique. In this example, we are creating an LNK file called “Test.lnk” that will be placed in the current user’s startup folder and will execute “cmd.exe /c calc.exe”, shown in Figure 7.


Figure 7: Performing dry-run and adding startup folder persistence

The startup folder persistence can then be removed, again using the “-m remove” argument, as shown in Figure 8. This will remove the LNK file from the current user’s startup folder.


Figure 8: Removing startup folder persistence

Scheduled Task Backdoor Persistence

The last technique highlighted here is the scheduled task backdoor persistence. Scheduled tasks can be configured to execute multiple actions at a time, and this technique will backdoor an existing scheduled task by adding an additional action. The first thing we need to do is look for a scheduled task to backdoor. In this case, we will be looking for scheduled tasks that run at logon, as shown in Figure 9.


Figure 9: Listing scheduled tasks that run at logon

Once we have a scheduled task that we want to backdoor, we can perform a dry run to ensure the command will successfully work and then actually execute the command as shown in Figure 10.


Figure 10: Performing dry run and adding scheduled task backdoor persistence

As you can see in Figure 11, the scheduled task is now backdoored with our malicious action.


Figure 11: Listing backdoored scheduled task

A backdoored scheduled task action used for persistence can be removed as shown in Figure 12.


Figure 12: Removing backdoored scheduled task action

Conclusion

Using reflective C# to assist in various phases of the attack lifecycle is a necessity in the offensive community and persistence is no exception. Windows provides multiple techniques for persistence and there will continue to be more discovered and used by security professionals and adversaries alike.

This tool is intended to aid security professionals in the persistence phase of the attack lifecycle. By releasing SharPersist, we at FireEye Mandiant hope to bring awareness to the various persistence techniques that are available in Windows and the ability to use these persistence techniques with C# rather than PowerShell.

Uighurs in China were target of two-year iOS malware attack – reports

Android and Windows devices also targeted in campaign believed to be state-backed

Chinese Uighurs were the target of an iOS malware attack lasting more than two years that was revealed last week, according to multiple reports.

Android and Windows devices were also targeted in the campaign, which took the form of “watering hole attacks”: taking over commonly visited websites or redirecting their visitors to clones in order to indiscriminately attack each member of a community.

Related: China’s hi-tech war on its Muslim minority

Continue reading...

Commando VM 2.0: Customization, Containers, and Kali, Oh My!

The Complete Mandiant Offensive Virtual Machine (“Commando VM”) swept the penetration testing community by storm when it debuted in early 2019 at Black Hat Asia Arsenal. Our 1.0 release made headway featuring more than 140 tools. Well now we are back again for another spectacular release, this time at Black Hat USA Arsenal 2019! In this 2.0 release we’ve listened to the community and implemented some new must have features: Kali Linux, Docker containers, and package customization.

About Commando VM

Penetration testers commonly use their own variants of Windows machines when assessing Active Directory environments. We specifically designed Commando VM to be the go-to platform for performing internal penetration tests. The benefits of using Commando VM include native support for Windows and Active Directory, using your VM as a staging area for command and control (C2) frameworks, more easily (and interactively) browsing network shares, and using tools such as PowerView and BloodHound without any worry about placing output files on client assets.

Commando VM uses Boxstarter, Chocolatey, and MyGet packages to install software and delivers many tools and utilities to support penetration testing. With over 170 tools and growing, Commando VM aims to be the de facto Windows machine for every penetration tester and red teamer.

Recent Updates

Since its initial release at Black Hat Asia Arsenal in March 2019, Commando VM has received three additional updates, including new tools and/or bug fixes. We closed 61 issues on GitHub and added 26 new tools. Version 2.0 brings three major new features, more tools, bug fixes, and much more!

Kali Linux

In 2016 Microsoft released the Windows Subsystem for Linux (WSL). Since then, pentesters have been trying to leverage this capability to squeeze more productivity out of their Window systems. The fewer Virtual Machines you need to run, the better. With WSL you can install Linux distributions from the Windows Store and run common Linux commands in a terminal such as starting up an SSH, MySQL or Apache server, automating mundane tasks with common scripting languages, and utilizing many other Linux applications within the same Windows system.

In January 2018, Offensive Security announced support for Kali Linux in WSL. With our 2.0 release, Commando VM officially supports Kali Linux on WSL. To get the most out of Kali, we've also included VcXsrv, an X Server that allows us to display the entire Linux GUI on the Windows Desktop (Figure 1). Displaying the Linux GUI and passing windows to Windows had been previously documented by Offensive Security and other professionals, and we have combined these to include the GUI as well as shortcuts to take advantage of popular programs such as Terminator (Figure 2) and DirBuster (Figure 3).


Figure 1: Kali XFCE on WSL with VcXsrv


Figure 2: Terminator on Commando VM – Kali WSL with VcXsrv


Figure 3: DirBuster on Commando VM – Kali WSL with VcXsrv

Docker

Docker is becoming increasingly popular within the penetration testing community. Multiple blog posts exist detailing interesting functionality using Docker for pentesting. Based on its popularity Docker has been on our roadmap since the 1.0 release in March 2019, and we now support it with our release of Commando VM 2.0. We pull tools such as Amass and SpiderFoot and provide scripts to launch the containers for each tool. Figure 4 shows an example of SpiderFoot running within Docker.


Figure 4: Impacket container running on Docker

For command line docker containers, such as Amass, we created a PowerShell script to automatically run Amass commands through docker. This script is also added to the PATH, so users can call amass from anywhere. This script is shown in Figure 5. We encourage users to come up with their own scripts to do more creative things with Docker.


Figure 5: Amass.ps1 script

This script is also executed when the shortcut is opened.


Figure 6: Amass Docker container executed via PowerShell script

Customization

Not everyone needs all of the tools all of the time. Some tools can extend the installation process by hours, take up many gigabytes of hard drive space, or come with unsuitable licenses and user agreements. On the other hand, maybe you would like to install additional reversing tools available within our popular FLARE VM; or you would prefer one of the many alternative text editors or browsers available from the chocolatey community feed. Either way, we would like to provide the option to selectively install only the packages you desire. Through customization you and your organization can also share or distribute the profile to make sure your entire team has the same VM environment. To provide for these scenarios, the last big change for Commando 2.0 is the support for installation customization. We recommend using our default profile, and removing or adding tools to it as you see fit. Please read the following section to see how.

How to Create a Custom Install

Before we start, please note that after customizing your own edition of Commando VM, the cup all command will only upgrade packages pre-installed within your customized distribution. New packages released by our team in the future will not be installed or upgraded automatically with cup all. When needed, these new packages can always be installed manually using the cinst or choco install command, or by adding them to your profile before a new install.

Simple Instructions

  1. Download the zip from https://github.com/fireeye/commando-vm into your Downloads folder.
  2. Decompress the zip and edit the ${Env:UserProfile}\Downloads\commando-vm-master\commando-vm-master\profile.json file by removing tools or adding tools in the “packages” section. Tools are available from our package list or from the chocolatey repository.
  3. Open an administrative PowerShell window and enable script execution.
    • Set-ExecutionPolicy Unrestricted -f
  4. Change to the unzipped project directory.
    • cd ${Env:UserProfile}\Downloads\commando-vm-master\commando-vm-master\
  5. Execute the install with the -profile_file argument.
    • .\install.ps1 -profile_file .\profile.json

Detailed Instructions

To start customizing your own distribution, you need the following three items* from our public GitHub repository:

  1. Our install.ps1 script
  2. Our sample profile.json
  3. An installation template. We recommend using commandovm.win10.install.fireeye.

*Note: If you download the project ZIP from GitHub it will contain all three items.

The install script will now support an optional -profile_file argument, which specifies a JSON profile. Without the -profile_file argument, running .\install.ps1 will install the default Commando VM distribution. To customize your edition of Commando VM, you need to create a profile in JSON format, and then pass that to the -profile_file argument. Let us explore the sample profile.json profile (Figure 7).


Figure 7: profile.json profile

This JSON profile starts with the env dictionary which specifies many environment variables used by the installer. These environment variables can, and should, be left to their default values. Here is a list of the supported environment variables:

  • VM_COMMON_DIR specifies where the shared libraries should be installed on the VM. After a successful install, you will find a FireEyeVM.Common directory within this location. This contains a PowerShell module that is shared by our packages.
  • TOOL_LIST_DIR and TOOL_LIST_SHORTCUT specify which directory contains the list of all installed packages within the Start Menu and the name of the desktop shortcut, respectively.
  • RAW_TOOLS_DIR environment variable specifies the location where some tools will be installed. Chocolatey defaults to installing tools in %ProgramData%\Chocolatey\lib. This environment variable by default points to %SystemDrive%\Tools, allowing you to more easily access some tools on the command line.
  • And, finally, TEMPLATE_DIR specifies a template package directory relative to where install.ps1 is on disk. We strongly recommend using the commandovm.win10.installer.fireeye package available on our GitHub repository as the template. If your VM is running Windows 7, please switch to the appropriate commandovm.win7.installer.fireeye package. If you are feeling “hacky” and adventurous, feel free to customize the installer further by modifying the chocolateyinstall.ps1 and chocolateyuninstall.ps1 scripts within the tools directory of the template. Note that a proper template will be a folder containing at least 5 things: (1) a properly formatted nuspec file, (2) a “tools” folder that contains (3) a chocolateyinstall.ps1 file, (4) a chocolateyuninstall.ps1 file, and (5) a profile.json file. If you use our template, the only thing you need to change is the packages.json file. The easiest way to do this is just download and extract the commando-vm zip file from GitHub.

With the packages variables set, you can now specify which packages to install on your own distribution. Some packages accept additional installation arguments. You can see an example of this by looking at the openvpn.fireeye entry. For a complete list of packages available from our feed, please see our package list.

Once you finish modifying your profile, you are ready for installation. Run powershell.exe with elevated privileges and execute the following commands to install your own edition of Commando VM, assuming you saved your version of the profile named: myprofile.json (Figure 8).


Figure 8: Example myprofile.json

The myprofile.json file can then be shared and distributed throughout your entire organization to ensure everyone has the same VM environment when installing Commando VM.

Conclusion

Commando VM was originally designed to be the de facto Windows machine for every penetration tester and red teamer. Now, with the addition of Kali Linux support, Docker and installation customization, we hope it will be the one machine for all penetration testers and red teamers. For a complete list of tools, and for the installation script, please see the Commando VM GitHub repository. We look forward to addressing user feedback, adding more tools and features, and creating many more enhancements for this Windows attack platform.

Commando VM: The First of Its Kind Windows Offensive Distribution


For penetration testers looking for a stable and supported Linux testing platform, the industry agrees that Kali is the go-to platform. However, if you’d prefer to use Windows as an operating system, you may have noticed that a worthy platform didn’t exist. As security researchers, every one of us has probably spent hours customizing a Windows working environment at least once and we all use the same tools, utilities, and techniques during customer engagements. Therefore, maintaining a custom environment while keeping all our tool sets up-to-date can be a monotonous chore for all. Recognizing that, we have created a Windows distribution focused on supporting penetration testers and red teamers.

Born from our popular FLARE VM that focuses on reverse engineering and malware analysis, the Complete Mandiant Offensive VM (“Commando VM”) comes with automated scripts to help each of you build your own penetration testing environment and ease the process of VM provisioning and deployment. This blog post aims to discuss the features of Commando VM, installation instructions, and an example use case of the platform. Head over to the Github to find Commando VM.

About Commando VM

Penetration testers commonly use their own variants of Windows machines when assessing Active Directory environments. Commando VM was designed specifically to be the go-to platform for performing these internal penetration tests. The benefits of using a Windows machine include native support for Windows and Active Directory, using your VM as a staging area for C2 frameworks, browsing shares more easily (and interactively), and using tools such as PowerView and BloodHound without having to worry about placing output files on client assets.

Commando VM uses Boxstarter, Chocolatey, and MyGet packages to install all of the software, and delivers many tools and utilities to support penetration testing. This list includes more than 140 tools, including:

With such versatility, Commando VM aims to be the de facto Windows machine for every penetration tester and red teamer. For the blue teamers reading this, don’t worry, we’ve got full blue team support as well! The versatile tool sets included in Commando VM provide blue teams with the tools necessary to audit their networks and improve their detection capabilities. With a library of offensive tools, it makes it easy for blue teams to keep up with offensive tooling and attack trends.


Figure 1: Full blue team support

Installation

Like FLARE VM, we recommend you use Commando VM in a virtual machine. This eases deployment and provides the ability to revert to a clean state prior to each engagement. We assume you have experience setting up and configuring your own virtualized environment. Start by creating a new virtual machine (VM) with these minimum specifications:

  • 60 GB of disk space
  • 2 GB memory

Next, perform a fresh installation of Windows. Commando VM is designed to be installed on Windows 7 Service Pack 1, or Windows 10, with Windows 10 allowing more features to be installed.

Once the Windows installation has completed, we recommend you install your specific VM guest tools (e.g., VMware Tools) to allow additional features such as copy/paste and screen resizing. From this point, all installation steps should be performed within your VM.

  1. Make sure Windows is completely updated with the latest patches using the Windows Update utility. Note: you may have to check for updates again after a restart.
  2. We recommend taking a snapshot of your VM at this point to have a clean instance of Windows before the install.
  3. Navigate to the following URL and download the compressed Commando VM repository onto your VM:
  4. Follow these steps to complete the installation of Commando VM:
    1. Decompress the Commando VM repository to a directory of your choosing.
    2. Start a new session of PowerShell with elevated privileges. Commando VM attempts to install additional software and modify system settings; therefore, escalated privileges are required for installation.
    3. Within PowerShell, change directory to the location where you have decompressed the Commando VM repository.
    4. Change PowerShell’s execution policy to unrestricted by executing the following command and answering “Y” when prompted by PowerShell:
      • Set-ExecutionPolicy unrestricted
    5. Execute the install.ps1 installation script. You will be prompted to enter the current user’s password. Commando VM needs the current user’s password to automatically login after a reboot. Optionally, you can specify the current user’s password by passing the “-password <current_user_password>” at the command line.


Figure 2: Install script running

The rest of the installation process is fully automated. Depending upon your Internet speed the entire installation may take between 2 to 3 hours to finish. The VM will reboot multiple times due to the numerous software installation requirements. Once the installation completes, the PowerShell prompt remains open waiting for you to hit any key before exiting. After completing the installation, you will be presented with the following desktop environment:


Figure 3: Desktop environment after install

At this point it is recommended to reboot the machine to ensure the final configuration changes take effect. After rebooting you will have successfully installed Commando VM! We recommend you power off the VM and then take another snapshot to save a clean VM state to use in future engagements.

Proof of Concept

Commando VM is built with the primary focus of supporting internal engagements. To showcase Commando VMs capabilities, we constructed an example Active Directory deployment. This test environment may be contrived; however, it represents misconfigurations commonly observed by Mandiant’s Red Team in real environments.

We get started with Commando VM by running network scans with Nmap.


Figure 4: Nmap scan using Commando VM

Looking for low hanging fruit, we find a host machine running an interesting web server on TCP port 8080, a port commonly used for administrative purposes. Using Firefox, we can connect to the server via HTTP over TCP port 8080.


Figure 5: Jenkins server running on host

Let’s fire up Burp Suite’s Intruder and try brute-forcing the login. We navigate to our Wordlists directory in the Desktop folder and select an arbitrary password file from within SecLists.


Figure 6: SecLists password file

After configuring Burp’s Intruder and analyzing the responses, we see that the password “admin” grants us access to the Jenkins console. Classic.


Figure 7: Successful brute-force of the Jenkins server

It’s well known that Jenkins servers come installed with a Script Console and run as NT AUTHORITY\SYSTEM on Windows systems by default. We can take advantage of this and gain privileged command execution.


Figure 8: Jenkins Script Console

Now that we have command execution, we have many options for the next step. For now, we will investigate the box and look for sensitive files. Through browsing user directories, we find a password file and a private SSH key.


Figure 9: File containing password

Let’s try and validate these credentials against the Domain Controller using CredNinja.


Figure 10: Valid credentials for a domain user

Excellent, now that we know the credentials are valid, we can run CredNinja again to see what hosts the user might have local administrative permissions on.


Figure 11: Running CredNinja to identify local administrative permissions

It looks like we only have administrative permissions over the previous Jenkins host, 192.168.38.104. Not to worry though, now that we have valid domain credentials, we can begin reconnaissance activities against the domain. By executing runas /netonly /user:windomain.local\niso.sepersky cmd.exe and entering the password, we will have an authenticated command prompt up and running.


Figure 12: cmd.exe running as WINDOMAIN\niso.sepersky

Figure 12 shows that we can successfully list the contents of the SYSVOL file share on the domain controller, confirming our domain access. Now we start up PowerShell and start share hunting with PowerView.


Figure 13: PowerView's Invoke-ShareFinder output

We are also curious about what groups and permissions are available to the user account compromised. Let’s use the Get-DomainUser module of the post-exploitation framework PowerView to retrieve user details from Active Directory. Note that Commando VM uses the “dev” branch of PowerView by default.


Figure 14: Get-DomainUser win

We also want to check for further access using the SSH key we found earlier. Looking at our port scans we identify one host with TCP port 22 open. Let’s use MobaXterm and see if we can SSH into that server.


Figure 15: SSH with MobaXterm

We access the SSH server and also find an easy path to rooting the server. However, we weren’t able to escalate domain privileges with this access. Let’s get back to share hunting, starting with that hidden Software share we saw earlier. Using File Explorer, it’s easy to browse shares within the domain.


Figure 16: Browsing shares in windomain.local

Using the output from PowerView’s Invoke-ShareFinder command, we begin digging through shares and hunting for sensitive information. After going through many files, we finally find a config.ini file with hardcoded credentials.


Figure 17: Identifying cleartext credentials in configuration file

Using CredNinja, we validate these credentials against the domain controller and discover that we have local administrative privileges!


Figure 18: Validating WINDOMAIN\svcaccount credentials

Let’s check group memberships for this user.


Figure 19: Viewing group membership of WINDOMAIN\svcaccount

Lucky us, we’re a member of the “Domain Admins” group!

Final Thoughts

All of the tools used in the demo are installed on the VM by default, as well as many more. For a complete list of tools, and for the install script, please see the Commando VM Github repo. We are looking forward to addressing user feedback, adding more tools and features, and creating many enhancements. We believe this distribution will become the standard tool for penetration testers and look forward to continued improvement and development of the Windows attack platform.