Before we dive into the project description, first things first, you can find the script in the repo on GitHub.

Disclaimer: Only use this tool on networks you own or where you have explicit permission to test.

In its current state, the script has the following capabilities:

• ICMP host discovery
• TCP connect scan to detect open ports
• Banner grabbing (best effort)
• Optional JSON export of scanning results

As input, a single host, a range of IP addresses, or a whole subnet as a scan target is mandatory. Optionally, a port range can be specified, and a JSON export of the results can be created.

Here are a few limitations I want to discuss. It is good to be aware of such limitations if you also want to use the script. And it can also be seen as roadmap for further improvement. So let me describe the limitations in detail and how they could be resolved.

1. Hosts might be missed due to failing ICMP discovery

The script uses a function called alive_check for host discovery. Using ICMP (ping) the script stores responsive hosts in a list. This list is then used as the basis for the TCP connect port scan. ICMP echo replies may be blocked/filtered or there can be a timeout and when a host does not send an echo reply it won’t be scanned.
To fix this issue a flag could be added to skip alive_check and just scan every IP address that was provided as input.

2. Banner grabbing is still passive and best effort.

The script uses grab_banner to (surprise): grab banners. At the moment it just passively awaits an answer from the remote host on a given port with banner = s.recv(1024).decode().strip(). This works best with server-first protocols that send a greeting banner immediately after the TCP connection is established (e.g., SSH, FTP or SMTP) Client-first protocols are not sending banners directly after the TCP connect, e.g., HTTP doesn’t send a response without a prior GET request. Also with TLS in place, there must be a TLS-handshake before we would get some info about the service using that specific port.

To optimize banner grabbing I have some ideas like to implement active probing for protocols like HTTP.

3. Large subnets and/or large number of ports will take a long time to scan

The script pings/scans one host after another and this can be a slow process when we scan many hosts and/or ports. I think one option for solving this problem would be multithreading. For me, this is the most interesting problem to solve right now. I have never implemented multithreading before, so I’ll need to read up on it.

4. Windows is currently not supported

This was just a pragmatic decision because I only tested the code on Linux and macOS. I certainly want to check what kind of adaptation is necessary to make it work on a Windows machine. I think only the ICMP implementation needs to be adapted, so this is just a small change.

My perspective on this discussion: Neither DoH nor DoT significantly improve privacy on their own. While encrypting DNS traffic prevents ISPs or other third parties from seeing the content of your DNS queries, they can still infer which websites you’re visiting by observing the Server Name Indication (SNI) field, which is part of the TLS handshake and includes the domain name being accessed.

RFC for Encrypted Client Hello (ECH)

I was already aware of ongoing efforts to encrypt the SNI as well, which would significantly contribute to privacy when combined with DoH / DoT. @rmbolger@mastodon.social pointed out that there is an active RFC draft for Encrypted Client Hello (ECH). With ECH, the client can encrypt its ClientHello to the TLS server. This includes the SNI field and a few other potentially sensitive elements like the Application Layer Protocol Negotiation (ALPN). The key privacy benefit is that third parties can no longer read the SNI and deduce the destination domain.

To return to DoH and DoT: I believe both protocols would really improve privacy, but only when combined with ECH. Therefore, widespread implementation of ECH is highly desirable.

Testing ECH Support in your setup

I wanted to know if ECH is already implemented, so I did a bit of research. It turns out Firefox already supports ECH.

On the server side, implementations are emerging too. For example, OpenSSL has a feature branch that supports ECH.

Since ECH depends on specific DNS records (notably HTTPS and SVCB) you need to use a DNS server that returns these records. They are mandatory for ECH and contain the public key for the encryption and some other metadata. Firefox users can enable DNS over HTTPS (DoH) to ensure proper resolution, as many default DNS servers do not yet provide HTTPS/SVCB records. I did this for my test, because normally I don’t use DoH.

To test whether ECH is working in your setup, visit: https://test.defo.ie/

If everything is working as expected (assuming you’re using Firefox), the site will display SSL_ECH_STATUS_SUCCESS. Chrome should also support ECH, though Safari does not as of now.

Real-World Examples

I also wanted to see how this works beyond the test site, particularly in terms of actual network traffic.

First, I captured TLS traffic in Wireshark without ECH. In this scenario, the SNI remains unencrypted, and the Server Name field displays the domain name mialikescoffee.com

Next, I looked at research.cloudflare.com, which supports ECH. In this capture, the Server Name Indicator is shown as cloudflare-ech.com, and the packet capture includes the Extension: encrypted_client_hello — confirming that ECH is working properly. In this case, a third party cannot determine which specific domain is being accessed.

Conclusion

Combining ECH and encrypted DNS significantly boosts privacy, as it prevents third parties (such as ISPs) from observing which domain a user is accessing. While the destination IP address is still visible, many sites today use CDNs with shared IPs, making it difficult to determine the exact website being visited.

Unfortunately, major websites have been slow to adopt ECH. For this reason, I used Cloudflare’s research page as an illustrative example.

If you administrate web servers, consider implementing ECH. If not, help spread the word to raise awareness about ECH and its benefits for privacy for all internet users.

At its core, deception involves deploying false IT assets within a network. They act as decoys to attract and expose attackers. Deceptive decoys can mimic legitimate systems, files, credentials, and other IT assets. They lead attackers into a monitored environment where their actions are generating noise and can be detected and analyzed. The intelligence gathered from these interactions helps security teams strengthen their defenses.

By integrating deception technologies into their security strategy, organizations enhance their ability to recognize and mitigate threats before they escalate into security breaches, such as ransomware attack or data exfiltration.

Deception technology can be categorized into varius types, with two of the most commong being honeypots and honey users. (Learn More).

Honeypots

A honeypot is a decoy computer system deployed within a network, positioned alongside production machines. Honeypots serve multiple purposes:

• Diverting malicious traffic away from critical systems
• Gathering intelligence on attacker behavior and techniques
• Strengthening security by using the insights gained to harden defenses

If this concept excites you, you can experiment by setting up your own honeypot. A cost-effective way to start would be to rent a cheap VPS and deploy a honeypot in the cloud. I previously wrote an article on hosting T-Pot, a collection of different honeypots developed by T-Systems—definitely worth checking out!

Honey Users

A honey user is a decoy account created in Active Directory (AD) with no special privileges. These fake accounts can help detect AD enumeration and password-guessing attacks. To be effective, a honey user should have an enticing username, such as “BackupAdmin” or “SuperUser”, that might attract an attacker’s interest..

By monitoring login attempts and access to these accounts, security teams can quickly identify malicious activity.

What are Canary Tokens?

When it comes to deception, a free and easy-to-use tool for defenders is Canarytokens.

Canarytokens are digital tripwires that can be deployed in various locations across your network. The core idea is to lure attackers into triggering them.

For example there is a Canarytoken DOCX file that could be named “top_secret.docx” to spark curiosity. If an attacker opens the file, instead of finding sensitive information, an alert is triggered - sending an email to the Security Operations Center (SOC) or generating an alert to the SIEM (Security Information and Event Management) system.

The possible applications for Canarytokens are endless. This makes them a versatile addition to your security arsenal.

Case Study: Deploying a Canary Token

After covering the theory, let’s dive into a practical example of how you can deploy your own Canarytoken.

To start, visit the Canarytokens Website and explore different token variations. You might find options that integrate into your infrastructure, enhancing your defense-in-depth strategy.

Using A DNS Canarytoken

A DNS Canarytoken is a special DNS name that triggers an alert whenever it is resolved. Here are two ways it can be effectively deployed:

1. Embedding in sensitive files - Place the fake DNS name into critical files like .bashrc or .bash_history. Many reconnaissance tools (e.g., nmap or Recon-ng) automatically collect and resolve DNS names during enumeration. If an attacker uses such a tool that resolves the DNS name, an alert will be triggered.

2. Inserting into internal documentation - If an attacker accesses internal documentation and attempts to resolve the embedded fake DNS name, the same detection mechanism is activated.

To demonstrate, I created a DNS token and stored it inside a simple shell script.

#!/bin/bash

# Running this script will resolve the DNS canarytoken and trigger an email alert

dig yourtoken.canarytokens.com

When this script is executed - or if an attacker scrapes and resolves the DNS name - the Canarytoken is triggered.

After running the script, I immediately received an email alert, proving that the Canarytoken successfully detected unauthorized activity.

Conclusion

Deception technologies such as honeypots, honey users, and Canarytokens provide a proactive approach to cybersecurity. By luring attackers into interacting with fake assets, security teams gain valuable intelligence while reducing the risk of undetected intrusions.

Have you ever considered using Canarytokens or a similar product or have you already implemented it in the past? Please drop me your thoughts. :)

If you’re serious about achieving your goals, there’s one simple but powerful rule: Write them down. Start by jotting down your goals, then track and review your progress regularly. This small habit can make a big difference.

The Science Behind Writing Down Goals

Writing down your goals might sound simple, but it’s highly effective. In fact, science supports this approach, showing that it significantly boosts the likelihood of success. Here’s why: Research consistently links written goals to higher success rates. This can be explained by two key factors:

1. External storage: The information about your goals is stored in a dedicated location and can be accessed and reviewed at any time. Revisiting your notes helps you stay focused and committed.
2. Encoding: This is the brain’s process for deciding whether information gets stored in long-term memory. Encoding is improved by writing, and therefore, you are more likely to remember what you have written down.

This is especially exciting for me because sharing this information with you aligns perfectly with one of my own goals for 2025: publishing a blog post every month. It’s a win-win—I get to help others while working toward my personal milestones.

The best part? You can start right now. You don’t have to go down the fancy road. Simply open your notes app or grab a journal, and jot down a few goals you’d like to achieve this quarter.

A Smarter Way to Set Goals

I have also some thoughts on the character of the goal itself and want to make it clear by using a chess analogy. Let’s say someone has the goal to reach an ELO score of 1.600. This isn’t an ideal goal because it’s abstract and depends on multiple factors, making it hard to track. Sure, the ELO score itself can be easily measured because it is just a number, but it won’t improve on its own.

So instead you should set goals like this:

• Play 1 hour of chess every evening
• Read 1 theory book every month
• Solve 50 puzzles every week

By breaking the ELO goal into smaller, actionable, and easily measurable steps, you create a clearer pathway to improvement.

Another example: If you want to improve your fitness, avoid vague targets like “getting fit”. Instead you can break it into specific actions like jogging three times a week or doing 15 push-ups daily.

What goals have been on your mind? Take just ten minutes today to write down your goals and outline a simple plan to achieve them. Writing your goals and breaking them into actionable steps is the first step toward success.

For this demonstration, I am using a server with Debian 12. If you want to try this setup, feel free to use any Linux distribution that suits your needs.

Dependencies

I installed some dependencies beforehand. This was of course the Podman package. Additionally, I installed the uidmap and slirp4netns packages, which are dependencies for running containers rootlessly. Another essential package is policykit-1, necessary to enabling “linger” on an unprivileged user. This feature keeps a user manager running after logouts, providing persistence for our container.
I also created the user containersrv and then connected to the server via SSH using this newly created user.

Running a httpd container with Podman

I am using httpd image from the Docker repository. Let’s create a directory in our home directory to use as a persistent volume for the httpd container.

mkdir ~/content

Then we can pull the container image and run the container with the following command. The DocumentRoot within the httpd container is /usr/local/apache2/htdocs/. We could change this in the httpd.conf, but to keep it simple, we’ll leave it as is for this demonstration.

podman run -d -p 8080:80 --name apache  -v /home/containersrv/content:/usr/local/apache2/htdocs/ docker.io/library/httpd

The Podman command does the following things:

1. Pulls the httpd container image from the Docker repository and runs the container named apache.
2. Maps port 80 within the container to port 8080 on our host OS. In a rootless context, this mapping is necessary because regular users cannot bind to port numbers below 1024.
3. Maps the DocumentRoot path in the container /usr/local/apache2/htdocs/ to /home/containersrv/content

Let’s put a little index.html file in our content directory and then view it in our browser by navigating to http://$ip:8080

echo "hello world. containers are awesome." > content/index.html

It worked; the content we just created is now visible.

Persist the container as a systemd service

If you reboot the server now, the container will exit and not be running anymore :(.
However, we want to serve our awesome little website on a regular basis. Luckily, Podman has a handy feature that allows us to generate a systemd unit file for our container.

First, let’s create the directory structure in our home directory:

mkdir -p ~/.config/systemd/user/

Then, we can change to the newly created directory and create the service unit file with this command:

cd ~/.config/systemd/user/
podman generate systemd --name apache --new --files

Let’s review the service file. We can see that is uses podman run as ExecStart action with all the options we specified before. When the service is stopped it first uses podman stop to stop the container and after that the container is completely removed with podman rm. This removal is efficient in terms of system resources and is unproblematic because we have a persistent volume for our index.html.

containersrv@containerlab:~/.config/systemd/user$ cat container-apache.service 
# container-apache.service
# autogenerated by Podman 4.3.1
# Sat Apr 27 08:01:21 UTC 2024

[Unit]
Description=Podman container-apache.service
Documentation=man:podman-generate-systemd(1)
Wants=network-online.target
After=network-online.target
RequiresMountsFor=%t/containers

[Service]
Environment=PODMAN_SYSTEMD_UNIT=%n
Restart=on-failure
TimeoutStopSec=70
ExecStartPre=/bin/rm \
	-f %t/%n.ctr-id
ExecStart=/usr/bin/podman run \
	--cidfile=%t/%n.ctr-id \
	--cgroups=no-conmon \
	--rm \
	--sdnotify=conmon \
	--replace \
	-d \
	-p 8080:80 \
	--name apache \
	-v /home/containersrv/content:/usr/local/apache2/htdocs/ docker.io/library/httpd
ExecStop=/usr/bin/podman stop \
	--ignore -t 10 \
	--cidfile=%t/%n.ctr-id
ExecStopPost=/usr/bin/podman rm \
	-f \
	--ignore -t 10 \
	--cidfile=%t/%n.ctr-id
Type=notify
NotifyAccess=all

[Install]
WantedBy=default.target

Now that we have our service unit file we still need to enable and start the service. However, before we are doing this we will stop and remove the container first.

podman stop apache
podman rm apache

Then we can enable and start our service. We are using systemctl --user because this allows us to run the service within our user context.

systemctl --user enable --now container-apache.service

To verify that our service and the container is running:

systemctl --user status container-apache
podman ps

Amazing, the service is active and running and the container is running as well.

As a final step, let’s enable lingering to ensure that the user’s manager persists after logouts, allowing the httpd container to continue running in the user context.

loginctl enable-linger

With lingering enabled, the httpd container will now run persistently under the user’s context.

Per default, it scans the well-known port range from 1 to 1023. One can specify their own port range by telling the script the first and last port. For example to scan for all ports from 21 to 100 you would use it like this:

./portscan.sh 10.0.0.1 21 100

The output looks something like this:

Scanning remote host 10.0.0.1 for open TCP ports in the range between 21 and 100
Port 22 is open
Port 80 is open

Below is the full script. You will probably find a more up-to-date version of the script on GitHub in the future. So don’t assume that this blog post will be updated automatically.

#!/bin/bash

# User should be able to input portrange or single port - otherwise scan well known ports

ip_address=$1
# Per default we are using well known ports. These are overwritten when the user passes port numbers as parameters
port_first=1
port_last=1023

if [ -z "$ip_address" ]; then
    echo 'You need to run the script like this: ./portscan.sh $IP [$firstport] [$lastport]'
    exit 1
fi

# If 3 arguments are given (IP address, first port and last port, port variables will be replaced by the user input)

if [ $# -eq 3 ]; then
    port_first=$2
    port_last=$3
fi

# Scan for open ports

echo "Scanning remote host $ip_address for open TCP ports in the range between $port_first and $port_last"

for (( port=port_first; port<=port_last; port++ ))
do
    (echo >/dev/tcp/"$ip_address"/"$port") &>/dev/null && echo "Port $port is open"
    sleep 0.01
done

So have fun reading, and see you soon :)

We are Spice Hut, a new startup company that just made it big! We offer a variety of spices and club sandwiches (in case you get hungry), but that is not why you are here. To be truthful, we aren’t sure if our developers know what they are doing and our security concerns are rising. We ask that you perform a thorough penetration test and try to own root. Good luck!

Preface

First, the usual disclaimer: you can use the tools presented here for your own network or during a penetration test if you’ve been authorized to do so. However, you must never use these tools against external systems without explicit permission.

Enumeration

First, we scan the server with nmap for open ports and use switches for Script Scan and Version Detection.

nmap -sV -sC $ip

We find that three different services are running on the server:

• 21 FTP
• 22 SSH
• 80 http / Apache

Upon closer inspection, it is noted that the FTP server allows anonymous access. Additionally, nmap kindly indicates that there is a folder with write permissions on the FTP.

When accessing the website in the browser, only a note appears stating that the site is currently under development.

If we enumerate the web server for directories, we find the directory /files. Very convenient, as that’s where the folder we can write to via FTP is located.

Initial Access

So, it’s relatively obvious to gain initial access by loading a reverse shell via FTP onto the server and then accessing it through the browser to execute the shell server-side and connect it to our listener.

We log in to the FTP server with anonymous / anonymous and navigate to the ftp folder. There, we can upload our reverse shell. You can use a PHP reverse shell, which you can find, for example, at Pentest Monkey.

First, we start a Netcat listener:

nc -lvnp 1234

After that we execute the reverse shell, which will then connect to our listener.

Now we have a shell as the user www-data.

The Secret Ingredient

In the root directory, we find the recipe.txt, which reveals the secret ingredient for the soup.

User Flag

In the directory /incidents, we find a pcap-ng file. We can simply download this using our browser by copying it to the web server’s directory.

cp suspicious.pcapng /var/www/html/files

With Wireshark, we can open the .pcapng file. When we analyze the network traffic, we see that someone in the past gained access to the server with a reverse shell. Upon closer examination of the TCP streams, we find the password for the user lennie.

We can log in as lennie with SSH on the server and find the user flag in the user’s home directory.

Root Flag

Under /home/lennie/scripts/, we find the shell script planner.sh. The script belongs to root and can be executed by our user.

#!/bin/bash
echo $LIST > /home/lennie/scripts/startup_list.txt
/etc/print.sh

We see that the script calls another script named print.sh. This script belongs to the user lennie and can therefore be edited by us. We modify it so that the root flag is copied to /tmp/root.txt.

#!/bin/bash
cp /root/root.txt /tmp/root.txt

Now we just need to execute planner.sh to subsequently find the root flag under /tmp.

Although this feature has been part of iOS and macOS for several months now, I still find it absolutely fascinating. Apple is helping to bring Mastodon out of its original niche and recognize the decentralized network as a fully-fledged social medium. I think Apple has done an excellent job here.

I hope this feature has a positive impact on how people use Mastodon and share content from the network with one another. Other messengers, like Signal, could take inspiration from this and offer similarly designed previews for Mastodon content. This would not only improve usability but also promote the visibility and acceptance of decentralized social platforms.

Regular expressions are especially helpful in if statements. For instance, they can be used to validate user input or extract and process specific elements from a text.

Syntax

To use RegEx in an if statement, the =~ operator is required. This allows a string to be matched against a regular expression.

if [[ "$input" =~ regex ]]; then
  # Command to execute if $input matches the regular expression.
else
  # Command to execute if $input does not match the regular expression.
fi

This if statement checks the content of the variable $input against a regular expression (not further defined here).

Here are some concrete examples for illustration:

Checking if $input is a number

In the following example, the if statement checks whether the content of $input is a whole number.

if [[ "$input" =~ ^[0-9]+$ ]]; then
  # Command to execute if $input is a whole number.
else
  # Command to execute if $input is not a whole number.
fi

Checking if $input consists of letters

With this regular expression, you can check if the content of $input consists exclusively of uppercase and lowercase letters.

if [[ "$input" =~ ^[A-Za-z]+$ ]]; then
  # Command to execute if $input consists of uppercase and lowercase letters.
else
  # Command to execute if $input does not consist of uppercase and lowercase letters.
fi

These two examples represent relatively simple applications of regular expressions. However, they can quickly become more complex. For creating your own regular expressions, I find the website regex101.com particularly helpful. In addition to comprehensive documentation, it also provides the ability to test and verify your own regular expressions with custom inputs. Have you ever used RegEx in if statements before? If so, feel free to share your experiences with me. :)