A post about two of the four Sliver C2 protocols: mutual TLS (mTLS) and WireGuard. I'll show how to use sessions and beacons with these protocols. Using Wireshark, you will also see what kind of traffic could be observed when you deploy such implants. Like in the previous Sliver-related posts, a couple of instructions for additional lab setup are included. I'll add a DNS server to make the traffic look more realistic.
Sliver C2 This post is part of a tutorial blog post series on Sliver C2 (v1.5.16). For an overview: click here.
Introduction After discussing Sliver beacon and session implants in general in 02 - Beacons and Sessions, I’ll now have a more detailed look at the four different C2 protocols you can choose from. This post covers the first two of them, which are mutual TLS (mTLS) and WireGuard. Both are strongly recommended in the official Getting Started Guide.
This post is about how to use Sliver implants (C2 agents) to remote-control target computers
from a Sliver C2 server. I'll showcase both the session mode, which establishes
an interactive session with immediate command execution and feedback, and the
beacon mode, which makes the implant connect back and fetch jobs in regular intervals.
To make following along easy, some instructions on lab setup are included.
Sliver C2 This post is part of a tutorial blog post series on Sliver C2 (v1.5.16). For an overview: click here.
Introduction This post demonstrates how to use so-called implants to remote-control a target machine from a Sliver C2 server. It is a follow-up to the previous one on Sliver C2 server installation (01 - Installation). To get familiar with the basics of Sliver, we’ll now add a (Windows) target machine to the setup.
This post is about how to install the Sliver C2 framework from BishopFox
on a blank Kali Linux server. It is meant as the kickoff post for a series
of tutorial posts on how to use Sliver, but targeting beginner users rather than experienced
red team veterans.
Sliver C2 Introduction Recently, I developed some interest into red teaming and wanted to try out a few things. As you might know, all of that is no fun without a command and control (C2) framework. Unfortunately, most of the well-known ones are terribly expensive (Cobalt Strike or SCYTHE). Not good for a few personal experiments at home.
Fortunately though, there are plenty of open source solution out there. Check out the C2 matrix and you get more choices than you can handle.
Write-up for the machine RE from Hack The Box.
A fun one if you like Client-side exploits. You check out the
website and find a blog with plenty of information on bad Office
macros and malware analysis. A writable SMB share called
"malware_dropbox" invites you do upload a prepared .ods file,
which is all you need for the initial shell.
The script that processes these uploads contains comments with
hints about downstream .rar file processing. You guess this
must be about the WinRAR ACE vulnerability, prepare an archive
which writes a web shell and voilà, you get another shell.
This is where the intended way would have been to upload yet
another malicious file, this time exploiting an XXE in Ghidra.
I did it in a different way though, by service abuse to
become SYSTEM. Surprisingly, this was not enough to read the
flag. It is encrypted with EFS and only the right user can
read it. As SYSTEM though it is easy to impersonate this user
since we get all the NT hashes and can pass them to WinRM,
which can be accessed remotely after forwarding the port.
RE Port scan As usual, I started with a full TCP port scan. Only two ports were open:
root@Kali:~# nmap -p- --reason --min-rate 2000 10.10.10.144 ... PORT STATE SERVICE REASON 80/tcp open http syn-ack ttl 127 445/tcp open microsoft-ds syn-ack ttl 127 ... Malicious ODS Macro Discovering the malware dropbox On port 80, accessed by IP, I found a website that redirects to “reblog.htb”. I added an entry to “/etc/hosts” to resolve this hostname to “10.
In this article I look at level 5 of flAWS.cloud, a
CTF-style cloud security game in teaching you basics of cloud security by
making you break into an AWS account. This level is a particularly interesting
one because it is remarkably similar to a high-profile hack that was big in the
news lately. CapitalOne [lost >100M customer records](https://krebsonsecurity.com/2019/07/capital-one-data-theft-impacts-106m-people/),
stolen from their S3 buckets. Presumably the attacker extracted credentials
from a misconfigured web application firewall (WAF) and then simply downloaded the
material. This is exactly what we will do in this level too.
OK, this is not exactly what we will do. This game focuses on cloud security only and is kept simple. There won’t be complex applications protected by WAFs, just a simple proxy on an EC2 instance serving all the websites you request. From there, the goal is to find out how to make it serve the private IAM credentials that have been configured for this machine. Once you have them, all that is left is to use them to impersonate the EC2 instance and exfiltrate some data.
This is a walkthrough for level 4 of flAWS.cloud, a
CTF-style cloud security game in which you have to find your way in to an AWS
account. This time you find a publicly available web server running on an EC2
machine. Since it hosts a password-protected website there is not much to do
with just that. But given the credentials gained from level 3 of this game you
can use the AWS API to find out plenty of sensitive information about the
machine. The crucial part is the ID of the root volume, which allows to list
corresponding VM snapshots. You notice that there is one snapshot with
misconfigured sharing permissions, making the snapshot publicly available.
Thus you can boot your own EC2 instance, mount a volume based on this snapshot
and get past the password protection that way.
In Level 3 of the game we gained initial foothold and can now move deeper into the account. Level 4 now starts at this page. We are being told there is a web server running on an EC2 machine.
Before you start, make sure you have the credentials from level 3 ready. You can put the into the “~/.aws/credentials” file as a profile and then reference them in all your API calls.
Long time ago I started flAWS.cloud, a CTF-style cloud security
game teaching you about cloud-specific vulnerabilities related to bad
configurations. Now I took it up again and here is a walkthrough of level 3.
Like before we have a public homepage hosted on S3. This time we find a git repository with
IAM credentials in the commit history. Using them we can list the buckets and
find the link to the next level.
The previous level 2 illustrated how ACL misconfiguration can accidentally open up S3 buckets to all AWS users anywhere on the world. This was enough to just get the secret we needed. This time it will not be that easy anymore. Again, the starting point is a public website and we can again just list the bucket. But now the secret is hidden.
EDIT 11th Nov 2019: changed the description of this level.
Write-up for the machine Carrier from Hack The Box.
This box is really fun since it allows you to try something yourself that you
otherwise only hear about in the news. BGP hijacking is required to get the
root flag. You start by checking out the admin interface of an ISP called
Lyghtspeed Networks. Fuzzing the web server, you find some documentation on
error codes which suggest you could log in with default admin credentials.
However, the password is a serial number of the device. Some UDP port scans
later you realize there is SNMP running and it spits out this number. Once
inside the admin interface you read some support tickets. One of them is about
an important FTP server is a specific network attached to a neighboring AS.
Also, there is a feature to check router status which turns out to be
vulnerable to command injection. This vulnerability turns into a shell on the
router. This was all easy but now the fun begins. You must carefully manipulate
the route advertisements to direct the traffic to this mysterious FTP server
over the compromised router. Dumping the traffic reveals the FTP password. The
root flag is now only one FTP download away. All in all a really interesting
challenge and a great way to learn more about how the Internet actually works.
Port scans A fast masscan scan returns only two open ports:
$ masscan -e tun0 -p 1-65535 --rate 2000 10.10.10.105 ... Discovered open port 80/tcp on 10.10.10.105 Discovered open port 22/tcp on 10.10.10.105 With nmap we can see we are in front of a Ubuntu Linux box with OpenSSH and Apache web servers running. Version 2.4.18 of Apache suggests the box is likely Ubuntu Xenial (click):
$ nmap -sV -sC -p 22,80 10.
Write-up for the machine Access from Hack The Box.
This one is a pretty easy box. The main challenges are processing
proprietary Windows files (MS Access DBs, MS Outlook PST files, Windows
shortcuts) on a Kali box and understanding stored Windows credentials.
To get started, enumerate to find open FTP and Telnet ports as
well as a web server. Ignore port 80 and log into FTP anonymously to find a
Microsoft Access database with a username and password inside. Use it to get a
shell via the Microsoft Telnet service available on port 23. To escalate
privileges, you can now use "runas" with saved admin credentials. On one of
the users' desktops there is a shortcut which is a hint to this solution.
However, it is also easily discovered by enumeration. Although not necessary to
get the flag, I demonstrate in the end of this post how to get the plaintext
admin password using impacket.
Port scans A quick port scan with masscan reveals a bunch of open ports:
$ masscan -e tun0 -p 1-65535 --rate 2000 10.10.10.98 ... Discovered open port 21/tcp on 10.10.10.98 Discovered open port 80/tcp on 10.10.10.98 Discovered open port 23/tcp on 10.10.10.98 nmap provides more details on these ports. They run the expected services on a Windows box:
$ nmap -sV -sC -p 21,23,80 10.10.10.98 ... PORT STATE SERVICE VERSION 21/tcp open ftp Microsoft ftpd | ftp-anon: Anonymous FTP login allowed (FTP code 230) |_Can't get directory listing: TIMEOUT | ftp-syst: |_ SYST: Windows_NT 23/tcp open telnet?
GarageBand from Apple is probably an amazing program for people who love to
listen to and create music. I don't, so I lately decided to get rid of these
unused 1s and 0s on my disk. Turns out it is not as easy as it sounds since Apple
does not like it if you tamper with the Mac OS experience they have in mind for
you. Consequently, there is no official uninstaller. It is not too hard though to
discover the files yourself and just delete them. Using GarageBand as the
example, this post is about how to navigate the Mac OS file system and purge
all traces of the Mac OS standard applications that nobody ever asked for.
tl;dr This post is about how to discover files on Mac OS for those apps Apple forgot to put an uninstaller onto the system. If you don’t care and just want to delete GarageBand right now, the short version is this: sudo rm -rf on the following list of directories should be all you need
/Applications/GarageBand.app /Library/Audio/Apple Loops/Apple/ /Library/Application Support/GarageBand /Library/Application Support/iLifeMediaBrowser/Plug-Ins/iLMBGarageBandPlugin.ilmbplugin ~/Library/Containers/com.apple.STMExtension.GarageBand ~/Library/Containers/com.apple.garageband10 ~/Library/Application Scripts/com.apple.garageband10 ~/Library/Application Scripts/com.apple.STMExtension.GarageBand ~/Library/Caches/com.apple.helpd/Generated/com.apple.garageband10.help*10.2.0 ~/Library/Caches/com.
Write-up for the machine Active from Hack The Box.
The machine is a very interesting exercise for those who do not work with
Active Directory domain controllers every day but want to dive deeper into
their inner workings. Basically, you find one such domain controller with
plenty of open ports. After a short distraction in form of a web server with no
content, you find that you get unauthenticated access to an SMB share with some
group policy files in it. Inside, you find an encrypted password. It is easy to
decrypt though since the key is public information. With these credentials, you
get not only the first flag but also access to the AD itself. Searching for
server principal names reveals that the Administrator account is
kerberoastable. With impacket and john, it is easy to crack the password of
this account. Now the root flag is only one execution of psexec away.
Enumeration Port scan We start as usual with a quick masscan to get open ports as fast as possible. It returns lots of results:
$ masscan -e tun0 -p 1-65535 --rate 2000 10.10.10.100 Starting masscan 1.0.4 (http://bit.ly/14GZzcT) at 2018-09-13 20:54:40 GMT -- forced options: -sS -Pn -n --randomize-hosts -v --send-eth Initiating SYN Stealth Scan Scanning 1 hosts [65535 ports/host] Discovered open port 53/tcp on 10.10.10.100 Discovered open port 9389/tcp on 10.