Lab 1.1 : Environment Orientation

Objectives

• Understand the lab environment for the course
• Preview labs for the course
• VM review

Orientation and Troubleshooting

1. Please ensure you are connected to the Internet and the VPN by following Lab 0.
2. This course is designed around a strong lab component to reinforce the concepts from the course material.
3. Each lab will clearly state if the lab environment is required. There is an attempt to keep labs local for portability but when not possible, we will VPN into a provisioned environment in sections 1 through 5 of the course, then a similar environment during section 6.
4. This course will stress the importance of redirecting traffic from the target environment to our command-and-control servers. Although we are attached to the target environment via the VPN, we want to ensure we logically separate the assets belonging to the target (red space) from our redirectors in our attack infrastructure (gray space) and our C2 servers and VMs (blue space).
5. Red space encompasses anything owned by the target.
6. Gray space is anything that is owned by a 3^rd party and not associated with the target nor the Red Team.
7. Blue space is anything that is owned/registered to the Red Team, any friendly assets.
8. Technically speaking, all assets are part of the same Local Area Network (LAN), but we want to treat each "space" with a different set of rules and best practices. During sections 1 through 5 you will be able to communicate directly from your VMs to target space, during section 6 there are routing rules in place to prevent those direct communications. In section 6 all communications must be redirected through gray space.
9. Although all assets will have private IP addresses due to the way the lab is built and hosted in a cloud environment, we will refer to many of the hosts with DNS entries.

10. When connecting to the lab environment, always double check your assigned ip addresses. IP addresses may change as you reconnect to the environment. Be methodical when troubleshooting network communications, start testing connections where you maintain control instead of generating unnecessary activity. For example, let's walk through the troubleshooting of a failed attempt to exploit a target.

    

11. As you can see, we want to use targets in gray space as a intermediary between our infrastructure in blue space and the systems we are attacking in red space. This will be further elaborated in section 2 of the course when we discuss attack infrastructure and redirection.

12. If everything is set up and an exploit is thrown through the proxy at the web server but there is no call back, then we have to methodically troubleshoot the issue. The first step is to test locally. It could be any one of these issues, listed in priority order.

    • Is there a good path between blue space and the proxy?
    • Is the redirector returning traffic from external sources to blue space?
    • Is the proxy able to communicate with the web server in red space?
    • Is the target able to communicate with redirector?
    • Is the exploit weaponized properly, has it been tested against a local test system?

13. Think of it as testing each of the communication paths identified with red arrows. First check the communication between blue and gray space. This means testing data flow, redirector or proxy settings, ip addresses, etc. This should always be tested first because you maintain control of all those assets. Then check that gray space is able to communicate with red space, this generates traffics and logs! Lastly, or sometimes firstly, ensure the exploit is weaponized for the system you are targeting, test the exploit in a local lab environment.

Lab Preview

Section 1

Lab 1.1: Environment Orientation

• We will discuss traffic flow and how to troubleshoot issues with network traffic.
• This lab will be completed locally without the lab environment.

Lab 1.2: Consuming Threat Intelligence

• We will start our Red Team engagement with the first phase by consuming Cyber Threat Intelligence (CTI) on the adversary that we plan emulate. This involves mapping to ATT&CK™ and creating an adversary plan. In certain engagements the adversary plan can act as a scorecard for the Blue Team. By giving the Blue Team the "answers to the test" we are able to work in concert to improve their abilities to detect and respond.
• This lab will be completed locally without the lab environment.

Lab 1.3: Red Team Planning

• Now that we understand the adversary that we will emulate, we will build a plan during the Planning Phase. Whether working as a single Red Team Operator or with multiple operators, plans are critical in staying on task, working towards an objective and also coordinating efforts across a team.
• This lab will be completed locally without the lab environment.

Lab 1.4: Reconnaissance and Password Attacks

• At the end of the first section we will conduct reconnaissance of the target and find users to target in our engagement. After finding valid usernames we will conduct a brute force attack to discover valid credentials.
• This lab requires the lab environment.

Lab 1.5: Bonus! Username Enumeration and Password Spraying

• In this bonus lab we will continue our enumeration of users. We will generate a list of nearly two million usernames and take advantage of a few site issues that will allow a large enumeration. After discovering a few more usernames we will do a password spraying attack to find additional valid credentials.
• This lab requires the lab environment.

Section 2

Lab 2.1: C2 Introduction with Empire

• In the first lab of section 2 we introduce the Empire C2 framework. We will dive deep into the functionality of the C2, how to create listeners, generate launchers, and control agents. These are foundational concepts that are implemented by other frameworks as well.
• This lab will be completed locally without the lab environment.

Lab 2.2: Cobalt Strike Framework

• In the last lab of the day we will explore the Cobalt Strike Framework. After this lab, students should feel comfortable with two different C2 frameworks. Red Teamers should seek expertise in multiple tools to avoid being beholden to a single tool.
• This lab will be completed locally without the lab environment.

Lab 2.3: Pivoting and Redirection

• This lab is not for the faint of heart, we will discuss a topic that distinguishes the new offensive security testers from the seasoned operators. This lab will cover various tools used for redirecting traffic between network segments, a critical skill for the Red Team.
• This lab will be completed locally without the lab environment.

Lab 2.4: Setting Up Redirectors

• In this lab we will provision ephemeral instances that will act as our redirectors that provide a buffer between our target and our command and control servers.
• This lab requires the lab environment.

Lab 2.5: Bonus! More Pivoting

• This lab is not for the faint of heart, we will discuss a topic that distinguishes the new offensive security testers from the seasoned operators. This lab will cover various tools used for redirecting traffic between network segments, a critical skill for the Red Team.
• This lab will be completed locally without the lab environment.

Section 3

Lab 3.1: Creating and Testing Payloads

• In this lab you will use your systems to create and test payloads and tools. Checking their susceptibility to detection and how to tweak them to bypass that detection.
• This lab will be completed locally without the lab environment.

Lab 3.2: Initial Access

• We will focus on initial access and host enumeration in the second lab of this section. We will demonstrate how to gain situational awareness and maintain operational security in this dangerous phase.
• This lab will be completed locally without the lab environment.

Lab 3.3: Discovery and Escalation

• Once it is clear that operating on the target is safe, then it's time to execute discovery and escalation.
• This lab will be completed locally without the lab environment.

Lab 3.4: Persistence

• The final lab of section 3 is to establish persistence on the target. Since this is a risky task, we will spend some time looking at the IOCs we are generating to understand our tooling and what we expect the Blue Team to find.
• This lab will be completed locally without the lab environment.

Section 4

Lab 4.1: Enumerating Active Directory with Different Tools

• In the first lab for this section we will explore Windows Active Directory. We will introduce multiple tools that allow for enumerations of the objects in Active Directory.
• This lab requires the lab environment.

Lab 4.2: Privilege Hunting

• In this lab we will use our newly learned enumeration tools to hunt for privileged access. We will also use BloodHound to visually map the relationships between Active Directory Objects
• This lab requires the lab environment.

Lab 4.3: User Impersonation

• Once we discover where the privileges are, we will use various methods to impersonate those users. Techniques like MakeToken, Pass-the-Hash, and Pass-the-Ticket.
• This lab requires the lab environment.

Lab 4.4: Lateral movement in AD

• We will end this section with an lab on lateral movement in active directory. Exploring techniques such as, RDP, Windows Remoting, WMI, DCOM, Scheduled Tasks, PSExec, and SCM.
• This lab requires the lab environment.

Section 5

Lab 5.1: AD Privilege Escalation

• We start section 5 with a few more topics focused on Active Directory. First, we will exploit misconfigurations in AD to escalate privileges. We will also abuse trust relationships to gain elevated privileges. This lab will cover techniques such as, Kerberoasting, Active Directory Certificate Services(ADCS) Abuse, and Resource-Based Constrained Delegation(RBCD) abuse.

• This lab requires the lab environment.

Lab 5.2: AD Persistence

• In this lab we leverage AD to establish persistence, using techniques like, targeted Kerberoasting, hidden user with DC Sync privileges, forcing password changes, and shadow credentials.
• This lab requires the lab environment.

Lab 5.3: Action on Objectives

• We conclude the Red Team Execution phase with our final action on objectives. In this lab we will collect sensitive data and exfiltrate it from the network. Our focus will be on maximizing the impact of our engagement to motivate the stakeholders to improve their security posture.
• This lab requires the lab environment.

Lab 5.4: VECTR

• Now that we have concluded the Red Team Execution phase of our engagement, we shift into the Closure phase. We spent some time to explore VECTR in the first section of the course, we will go back to VECTR for the purpose of documenting our actions and reporting.
• This lab will be completed locally without the lab environment.

Section 6

Immersive Red Team CTF

• The final lab of the course is to use the skills gained throughout the course against a modified version of the lab environment. Stronger security controls will be applied as the organization has implemented the recommendations of a prior Red Team engagement.

VM Review

You've just been given a brand new VM, think of it as any other system that you might touch for the first time. The first question that you should always seek to answer is: "Is it safe to op on this system?"

This is not a course on malware, but malware is a threat to every Red Team Operator for multiple reasons: 1. Malware indicates the presence of another adversary
2. Malware is always a risk to the parent organization
3. Malware may grant another adversary access to the system
4. Malware may record and transmit your actions
5. Finding malware on a system should pause the engagement
6. Incident Responders must start an investigation

Prepare the VM for this lab by running:

sudo /labs/sec-1/orientation/setup.sh

1. Network connections and running processes are two things that should always be checked on every system you touch. Sometimes the information from the system tools may be altered by a rootkit or by trojaned or dorked binaries/scripts. Let's first look at network connections by running the following command.

sudo ss -auntp

or

sudo ss -a -u -n -t -p

• ss is the binary used to check sockets, think of it as a newer version of netstat for Debian based systems
• -a to display listening and established sockets
• -u for UDP
• -n for no DNS resolution of addresses
• -t for TCP
• -p for processes associated with the socket (Must be root)

2. You should see a process listening on TCP port 54321. This ss command should give you a pid or process id, check your specific output for the exact pid.

tcp LISTEN 0 10 0.0.0.0:54321 0.0.0.0:* users:(("[ext4-rsv-conve",pid=93219,fd=3))

3. The beauty of the Linux operating system is that you have many tools to help answer any question you might have. Using simple bash built-ins and standard binaries we can start looking into this process. First let's look at our process list with:

sudo ps -ef

4. We don't see the process in question! Why is that? Let's check on ps

which ps

file /bin/ps

cat /bin/ps

We first ran which to find out what file has precedence when we run the command ps. We see that it is /bin/ps, we then use file to read the file header and determine what type of file is at /bin/ps and we see that instead of a 64-bit ELF (Executable and Linking Format) binary, we have a bash shell script. Looking at the contents we see there is some tomfoolery afoot!

5. When we run ps from the commandline a bash script is called. This script runs /bin/sp and then filters the output using grep. Let's see what happens if we run /bin/sp directly without the filtering.

sudo /bin/sp -ef

file /bin/sp

Now we can see the process that has the listening port. This process is masquerading as a kernel module, you can see that there are square brackets in the process name, indicative of a kernel module. The dead giveaway that it is not a real kernel module is the high pid and the attached pseudo terminal.

6. Let's continue to investigate the process using /proc files. List the files under the pid:

sudo ls -al /proc/<PID>/

All the information on the process is available in the /proc directory. The current working directory is listed under /proc/<PID>/cwd. It points to /dev/shm which is usually a temporary filesystem which usually lives in RAM, a common location for Linux based malware because it is world writeable and will be unlinked when the system reboots.

7. We also see that the executable has been deleted after the malware was executed. We can pull the executable out of memory by copying it to another location.

sudo cp /proc/<PID>/exe /tmp/malware

file /tmp/malware

Now we have an ELF that we can continue to investigate the binary itself.

strings /tmp/malware

Notice the plaintext strings in the binary, these are indicators to what the malware might do. We also see symbols to libc functions that also give clues to the capabilities of the malware. A notable symbol is socket@@GLIBC_2.2.5 indicating the malware has network communications.

8. We can also check the environment of the process with:

sudo strings /proc/<PID>/environ

Notice the cheeky environment variable MALWARE=This is kernel module, I promise along with some other clues.

9. There is a lot more to look at but we'll scope down our research to the file descriptors the process currently has open.

sudo ls -al /proc/<PID>/fd

All file descriptors have been "nulled out" except for the socket. - Standard in (stdin) is file descriptor 0, it is set to /dev/null - Standard out (stdout) is file descriptor 1, it is set to /dev/null - Standard error (stderr) is file descriptor 2, it is set to /dev/null - But we have a unique file descriptor that is mapped to a socket, this should be bound to port 54321

10. Let's use another tool, lsof, to find a "list of open files".

sudo lsof -p <PID>

We can now see that the socket is mapped to TCP *:54321 (LISTEN)

11. Let's connect to the malware and see what happens.

nc 127.1 54321

12. Let's stop our investigation here and clean up our VM. Run the following to restore the VM to a safe state. In this case there is no persistence mechanism.

sudo kill <PID>

sudo cp /labs/sec-1/orientation/ps.orig /bin/ps

Conclusion

This lab provided an overview of the lab environment and how traffic will flow between the VM, systems in gray space, and targets in red space. A good troubleshooting methodology is important to isolate issues effectively. This lab also introduced the labs for the remainder of the course. Lastly, we investigated a suspicious listener using tools available on the system. We took advantage of all the information in /proc to understand exactly what the process is doing. This abbreviated investigation is a critical skill when exploring each new system that you touch. This is an important step to ensure he safety of your engagement, your tradecraft, and your tools.