Tales of a red teamer: Deploying shenanigans to Windows with Ansible

Deployment is commonly referred to as “the process of distributing the red team’s malware into the blue team’s machines”. Ansible provides a mechanism to connect to a Window machine, configure it, run command(s), and copy files to the target. Therefore, I often say, “If it’s good for sys admins, it’s good for red team”. In this blog post, I have provided an Ansible playbook that can be used to distribute the red team’s shenanigans to a list of targets, regardless of the red teamer’s host OS.

DISCLAIMER

The information contained in this blog post is for educational purposes ONLY! HoldMyBeerSecurity.com/HoldMyBeer.xyz and its authors DO NOT hold any responsibility for any misuse or damage of the information provided in blog posts, discussions, activities, or exercises. 

DISCLAIMER

Background

Red teaming

The term “red teaming” has been gaining a lot of traction in the enterprise world. In the enterprise landscape, red teaming refers to a team of individuals who attack enterprise machines. However, in this blog post, red teaming refers to a red team in a red vs. blue competition like CCDC or ISTS.

WinRM

Simply put, WinRM is the SSH of Windows. However, WinRM is not as intuitive as SSH on Linux and can be very complicated to setup. But this blog post simplifies that process because Ansible provides a script on Github to setup WinRM for you.

How to setup WinRM on a Windows machine

  1. Spin up a Windows VM and login
  2. Start a Powershell prompt as Administrator
  3. Set-ExecutionPolicy Unrestricted
    1. Enter “Y” to allow this script to run unrestricted
  4. powershell -NoProfile -ExecutionPolicy Bypass -Command "iex ((new-object net.webclient).DownloadString('https://raw.githubusercontent.com/ansible/ansible/devel/examples/scripts/ConfigureRemotingForAnsible.ps1'))"
  5. netstat -ano | findstr "LIST"
    1. If there is a service listening on ports 5985 and 5986 that should be WinRM

Install/Setup Ansible + PyWinRM

  1. MacOS
    1. brew install python3 python-pip3
    2. pip3 install ansible pywinrm
  2. Ubuntu
    1. apt-get install python3 python-pip3
    2. pip3 install ansible pywinrm
  3. Ansible docs
    1. Ansible installation guide
  4. Ansible PyWinRM docs
    1. Windows Remote Management
    2. WinRM+Ansible
    3. Managing Windows Servers with Ansible

Download Ansible deployment template

  1. git clone https://github.com/CptOfEvilMinions/RedTeaming-Public.git
  2. cd RedTeaming-Public/WindowsDeployment

Setup targets with credentials

In most competitions, there will be one box per team that is the domain controller and multiple Windows clients. In some cases, these boxes may use different usernames and passwords. This playbook provides templates for when all the Windows targets use the same credentials or when targets use different credentials.

Setup multiple targets with the SAME credentials

Configure hosts.ini

  1. cp hosts-same-pass.ini hosts.ini
  2. vim hosts.ini and add IP addresses under [windows-targets]

Configure group_vars/windows.yml

  1. cp group_vars/windows-same-pass.yml group_vars/windows.yml
  2. vim group_vars/windows.yml and set:
    1. ansible_user – Set to an administrator account on box
    2. ansible_password – Enter the password for the account above

Setup multiple targets with DIFFERENT credentials

Configure hosts.ini

  1. cp hosts-diff-pass.ini hosts.ini
  2. vim hosts.ini and add:
  3. Create hosts group and add each group name under “[windows:children]”
  4. Under each host group add IP addresses

Configure group_vars/windows.yml

  1. cp group_vars/windows-diff-pass.yml windows.yml
  2. vim group_vars/<host group name>.yml and set:
    1. ansible_user – Set to an administrator account on box
    2. ansible_password – Enter the password for the account above
  3. vim group_vars/<host group name>.yml and set:
    1. ansible_user – Set to an administrator account on box
    2. ansible_password – Enter the password for the account above

Adding shenanigans

This playbook provides roles to detonate malware on targets via a binary or a web drive-by. All binaries being pushed to a target must be a Windows executable and it MUST end with “.exe”. Web drive-by support is for platforms like Powershell Empire that will download and execute a malicious stager via HTTP.

Add web drive-by

  1. vim cmd/malicious_cmds.txt and add commands
    1. Any line starting with a “#” will be treated as a comment

Add binaries

  1. vim group_vars/all.yml and set:
    1. windows_malware_loc – Location binaries will be copied too AND executed from
    2. Default: ‘C:\Windows\System32\’
  2. cp <malicious binary name>.exe exes/<malicious binary name>.exe
    1. Binary MUST have an extension of “exe”

Adding shenanigans roles

Enable RDP

  1. vim deploy_malware.yml and uncomment “roles/persistence/setup_rdp.yml”

Add users

  1. vim deploy_malware.yml and uncomment “roles/persistence/add_users.yml”

Deploy the minions!!!!!!

The screenshot below is an output of Ansible when we run our playbook on a remote host. First, you will see Ansible “Gathering facts” about the machine – OS type, OS version, etc. Next, it will copy our Metasploit MSFvenom executable to the remote machine(hello.exe) and execute it. Lastly, Ansible will run our Powershell Empire web drive-by attack to start an agent.

  1. ansible-playbook -i hosts.ini deploy_malware.yml

 

 

Spread the love: Defenders

Prefetch

Mandiant defines prefetch as “a performance enhancement feature, first introduced in Windows XP, designed to shorten load times during boot and application startup. The operating system stores prefetch files, denoted with extension .PF, in the directory %systemroot%\prefetch. Forensic investigators often use the prefetch as a source of evidence of executable files that previously ran on a system.” The screenshot below shows an entry for our malicious binary. This entry contains the name of the binary “hello” and a timestamp indicating the last time it was executed.

Ansible async logs

Ansible async logs are located at C:\Users\<User>\AppData\Local\Temp\.ansible_async. The logs files are not very helpful but they may contain the command that was run. The screenshot below shows a log entry for the MSFvenom binary(hello.exe) but not for Powershell Empire. Furthermore, the log file includes timestamps, if the command ran successfully, and the PID .

Windows firewall

By default, the script provided by Ansible to setup WinRM will allow connections from any remote IP addresses. In an enterprise environment, you can strict which remote IPs can use WinRM. For example, you may limit remote IPs to a set list of management servers by IT or restrict it to the IT subnet.

The steps below have a similar process that can be applied via Group Policy. If this is set via Group Policy, it will take effect on all computers within the domain linked to that policy.

  1. Run > “wf.msc”
  2. Right-click “Allow WinRM HTTP[s]” within the “Inbound rules” page and select “Properties”.
  3. Select the “Scope” tab
  4. Select “These IP addresses” under the “Remote IP address” section
    1. Select “Add” and enter “<IP address list or a CIDR>”
  5. Apply the new settings

Windows event viewer

Powershell logs

The logging for Powershell in Windows 10 is impressive. By default, almost all actions performed by Powershell are logged – an incident responders dream. The screenshot below is showing the Powershell Empire web drive-by command ran by Ansible. The Mandiant report provided below, demonstrates a more in-depth approach for investigating Powershell with Windows Event Viewer.

  1. Open Windows Event Viewer
  2. Event Viewer (Local) > Applications and Services Logs > Windows Powershell

Disable WinRM

This is a very common mitigation in competitions but not so much in the enterprise. WinRM is usually setup at the request of the red team to do the things discussed above. Typically, it is NOT scored and therefore does not need to be running. IN A COMPETITION, disable services that don’t need to be running to reduce the attack surface.

  1. Open a Powershell prompt as Administrator
  2. net stop WinRM

DISCLAIMER

The information contained in this blog post is for educational purposes ONLY! HoldMyBeerSecurity.com/HoldMyBeer.xyz and its authors DO NOT hold any responsibility for any misuse or damage of the information provided in blog posts, discussions, activities, or exercises. 

DISCLAIMER

Resources/Sources

Leave a Reply

Your email address will not be published. Required fields are marked *