-
Notifications
You must be signed in to change notification settings - Fork 5
Add blog post for ENGR 1A Cyber Lab: Building Our Own Modular Malware #205
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,77 @@ | ||
--- | ||
title: Mastering Offensive Security, Building Our Own Modular Malware | ||
authors: [Samyukhtha Rajkumar Sridevi] | ||
category: Projects | ||
tags: [fall-2024, engr1a-cyber-lab] | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This is on me for not specifying the tags, but could we have a separate "cyber-lab" and a "engr-1a" tag? Thank you! |
||
description: Building our own modular malware | ||
--- | ||
|
||
# Mastering Offensive Security: Building Our Own Modular Malware | ||
## Introduction | ||
For our final project in the ENGR 1A Cyber Lab, my group and I designed and implemented a complete offensive security framework. Combining key concepts from the course (such as enumeration, exploitation, privilege escalation, persistence, and command-and-control (C&C)) we built our own modular malware. We used an attack virtual machine to attack and exploit a target virtual machine. Each stage taught us something new about offensive strategies, system vulnerabilities, and practical cybersecurity applications. | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Also on me for not telling you, but could the markdown be formatted with one sentence = one line? Thank you! |
||
|
||
This post provides a detailed overview of our project and reflects on what I learned. | ||
|
||
## Enumeration | ||
We began with enumeration, the process of identifying additional potential vulnerabilities, open services, versions, etc. Our code conducted a ping sweep across a specified IP address range, detecting whether each host was active or inactive by interpreting ICMP responses. This technique allowed us to map out the network and store active IP addresses for subsequent exploitation. | ||
|
||
**Key Features:** | ||
- Ping sweep command: Identified active hosts through ICMP responses. | ||
- Automation: Looped through IP addresses to test connectivity. | ||
- Results: Marked hosts as "up" or "down" for further analysis. | ||
|
||
## Exploitation | ||
Next, we focused on exploitation to gain remote code execution (RCE) on remote from our attack virtual machine onto our target virtual machine, targeting vulnerabilities in services and configurations. My group and I implemented two key exploits: | ||
|
||
1. **Shellshock (CVE-2014-6271)**: We exploited a vulnerable bash environment by injecting a malicious payload into the ```User_Agent``` HTTP header. This payload downloaded a script (```server.py```) to the target system, enabling us to execute arbitrary commands. | ||
2. **FTP Server Backdoor (CVE-2015-3306)**: This exploit allowed us to read and write arbitrary files on the target machine using FTP commands like SITE CPFR and SITE CPTO. | ||
|
||
Seeing these exploits in action gave us a deeper understanding of how attackers leverage common vulnerabilities. | ||
|
||
 | ||
 | ||
|
||
## Privilege Escalation | ||
After gaining access, the next step was to escalate privileges from a standard user to a root user and gain administrator priviliges. We used two different techniques: | ||
|
||
1. **Writable ```/etc/passwd```**: We modified the ```/etc/passwd``` file to add a new user with UID 0 (root). This gave the new user administrative privileges. To test, we switched to the new account and confirmed we had root access. | ||
 | ||
 | ||
|
||
2. **SUID Exploit on pexec**: We identified a binary (```pexec```) with the SUID bit set. By executing commands through ```pexec```, we started a new shell with root privileges. | ||
 | ||
 | ||
 | ||
We can see that we are now the root user. | ||
|
||
These techniques allowed us to bypass user restrictions and gain full control over the system, showcasing how misconfigurations and weak permissions can be exploited. | ||
|
||
## Persistence | ||
To ensure we could maintain access to the compromised system, my group and I implemented persistence techniques that allowed us to regain control even after a reboot or malware removal attempt. | ||
|
||
1. **Shell Startup Commands**: We modified bash initialization files, such as ```.bashrc```, to execute our payload whenever the system rebooted. | ||
2. **Hidden Root Account**: In the privilege escalation step, we created a hidden user account with root access. The account credentials were encrypted for additional stealth. | ||
|
||
These measures ensured our control over the target system even after reboots. | ||
|
||
## Command and Control (C&C) | ||
The command-and-control (C&C) phase enabled us to manage and interact with the compromised system remotely. | ||
|
||
**Key Features:** | ||
1. **Screenshot Capture**: We programmed the payload to take screenshots of the target system’s screen. These were saved as image files for later review and analysis. | ||
2. **File Exfiltration**: The payload searched for sensitive files on the target system. These files were securely transferred to our attacker machine for further use. | ||
|
||
These features provided insights into the target’s activities and access to valuable information. | ||
|
||
## Kill Switch | ||
To maintain operational security, we added a "kill switch" feature. This functionality allowed the attacker to remotely terminate the malware by sending a designated command. The script (```server.py```) then self-deleted, leaving no trace of its existence. | ||
 | ||
 | ||
|
||
## Lessons Learned | ||
This project was a deep dive into offensive security, and the following are some valuable insights gained along the way: | ||
|
||
- **Network Security**: Misconfigurations and weak permissions create opportunities for exploitation. | ||
- **Privilege Escalation**: Simple mistakes, like writable critical files, can lead to catastrophic consequences. | ||
- **Persistence and Detection**: Attackers use stealthy techniques to remain undetected, emphasizing the need for robust monitoring. | ||
- **The Importance of Patching**: Many exploits rely on unpatched vulnerabilities. Regular updates are crucial. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Unfortunately due to a quirk in our site long titles cause formatting issues - I love the title, so feel free to move it to the description or something, but please shorten it a bit