Disclaimer

This walkthrough is for educational purposes only. All activities were performed on legally authorised TryHackMe systems.

Initial Reconnaissance

I scanned the IP with Nmap using this command:

sudo nmap --top-ports 500 -sV 10.81.173.106

Command explained:

• --top-ports 500 — scan the 500 most common ports
• -sV — service version detection

While the scan was running, I decided to check if there was a website running. There was.

I started exploring the site and found a page called Host Manager, which had a login on it. Interesting. I looked around more but found nothing else, so I went back to check my Nmap results.

Digging Into Open Ports

Port 22 is running SSH version OpenSSH 7.2p2, so I looked for known vulnerabilities and found CVE-2018-15473, a race-condition-based username enumeration bug. I’ve had a bad experience with this one before, and it didn’t seem useful here either, so I moved on.

The next thing I had was Apache JServ running on port 8009. I had no idea what it was, and this was also my first time dealing with Apache Tomcat, so I decided to read up on it:

Apache Tomcat is a Java application server that executes Java code like JSP files and servlets to generate responses for HTTP requests. It has a Manager panel used to manage applications deployed on the server.

Apache JServ Protocol (AJP13) is a protocol Tomcat uses to listen for requests from services like web servers and load balancers. It’s typically not meant to be exposed directly to the internet.

So port 8009, running AJP, was a security misconfiguration by itself. I researched further and found it was vulnerable to CVE-2020-1938: Ghostcat. This vulnerability lets attackers read hidden files, and sometimes take full control of a server, by abusing Tomcat’s AJP connector.

Chasing Ghostcat (CVE-2020-1938)

I picked an exploit off GitHub to test it out:

GitHub: Hancheng-Lei/Hacking-Vulnerability-CVE-2020-1938-Ghostcat

After a few tweaks, I got it running, and it confirmed the vulnerability was real — I was able to read a protected file over Ghostcat/AJP. It returned actual file contents: the XML from WEB-INF/web.xml, including the Apache license and web app configuration. Time to look for juicier files.

Since WEB-INF/web.xml was readable, I figured other configuration files might be too. I made a list and went through them one by one:

• WEB-INF/application.properties — Spring Boot application configuration
• WEB-INF/context.xml — Tomcat context configuration
• META-INF/context.xml — application metadata configuration
• WEB-INF/spring-security.xml — Spring Security configuration (authentication)
• WEB-INF/faces-config.xml — JSF (Java web framework) configuration
• WEB-INF/application.yml — Spring Boot YAML configuration
• WEB-INF/db.properties — database connection properties
• WEB-INF/database.properties — database credentials/config
• conf/tomcat-users.xml — Tomcat Manager credentials (logical guess, but AJP couldn’t reach it)

Guess how many I found. If you guessed zero, you’re right. Every single one came back HTTP 500 — FileNotFoundException. Was I hallucinating this whole vulnerability? What if the tool wasn’t working right? Metasploit has a module for Ghostcat too, so I ran that to sanity-check myself:

The Metasploit scan confirmed the tool was working fine. It was me screwing something up, and I couldn’t figure out what.

While I was at it, I also tried the Metasploit Tomcat Manager brute-force module:

It ran through a list of default and weak passwords for Tomcat Manager, but every single one was wrong. Dead end.

Backtracking: Tomcat Manager’s Default Creds

I went back and reopened the site, and remembered the Host Manager login page from earlier. I tried a few passwords, failed, and got a 401 — Unauthorised message.

Very odd error message for a login page. On a whim, I tried the exact username and password shown on the page itself, and it worked.

I WAS IN. I sat there a little dumbfounded — I had a demo-looking username and password staring at me the whole time, and instead I went and brute-forced Tomcat Manager and chased Ghostcat down a hole. But that’s cybersecurity for you.

A dead end on path X isn’t a failure; it’s just the map telling you it’s time to unlock path Y. — me

Getting a Shell: WAR File Upload

Now that I was in, the way forward was simple: drop a reverse shell as a .WAR (Web Application Resource), set up a listener, trigger the payload, and get a shell.

I first generated a Java web-based reverse shell with revshells.com and uploaded it:

Deployed it, triggered it…

Nothing. No time to debug it. I deleted the file from the server and generated a fresh payload with msfvenom instead:

New payload, new listener. Deployed it, and boom — got a reverse shell.

Found the user flag. Now it’s time for root.

Privilege Escalation: Writable Cronjob Script

I checked the user’s home directory and looked at file permissions:

ls -la
total 48
drwxr-xr-x 4 jack jack 4096 Aug 23  2019 .
drwxr-xr-x 3 root root 4096 Aug 14  2019 ..
-rw------- 1 root root 1476 Aug 14  2019 .bash_history
-rw-r--r-- 1 jack jack  220 Aug 14  2019 .bash_logout
-rw-r--r-- 1 jack jack 3771 Aug 14  2019 .bashrc
drwx------ 2 jack jack 4096 Aug 14  2019 .cache
-rwxrwxrwx 1 jack jack   26 Aug 14  2019 id.sh
drwxrwxr-x 2 jack jack 4096 Aug 14  2019 .nano
-rw-r--r-- 1 jack jack  655 Aug 14  2019 .profile
-rw-r--r-- 1 jack jack    0 Aug 14  2019 .sudo_as_admin_successful
-rw-r--r-- 1 root root   39 Jul 12 01:47 test.txt
-rw-rw-r-- 1 jack jack   33 Aug 14  2019 user.txt
-rw-r--r-- 1 root root  183 Aug 14  2019 .wget-hsts

Two things jumped out: id.sh is world-writable (rwxrwxrwx), and test.txt is owned by root with a timestamp from just a few hours ago, not 2019 like everything else. That combination screamed cronjob to me — something running as root, on a schedule, was touching this directory, and id.sh was fair game to overwrite.

I tested the theory with something simple:

echo "cat /root/root.txt > /home/jack/root_flag.txt" > id.sh

I waited for the next run.

Root flag found.

Key Takeaways

Thanks for reading. Happy hacking.

Disclaimer

This walkthrough is for educational purposes only. All activities were performed on legally authorised TryHackMe systems.

Initial Reconnaissance

I started with a basic Nmap scan to identify open ports and services:

nmap -sC -sV -p- -v <IP>

While the scan was running, I decided to check if there was a website running. There was. I checked the source code (Ctrl+U) but found nothing useful, so I moved on to directory enumeration.

Directory Enumeration with ffuf

I copied the URL and ran ffuf against it. You can use dirbuster or gobuster too. I just prefer ffuf because it’s fast.

Advice — Tools don’t matter. What matters is whether you understand what you’re doing. Tools come and go; logic and skill stay.

The wordlist I used is from SecLists, specifically common.txt.

ffuf -u http://<IP>/FUZZ -w common.txt -t 100

Here are the results:

Exploring /files

There is a /files directory. I copied the URL and opened it in my browser:

I opened notice.txt and spotted a name: Maya. Interesting. I checked the other files and directories but nothing stood out. Meanwhile, my Nmap scan finished:

Digging Into Open Ports

Port 21 is running FTP with anonymous login enabled. I logged in and poked around, but found the same files we already saw in the browser. Nothing new. Time to switch.

Port 22 is running OpenSSH 7.2p2. I went online to look for known vulnerabilities and found CVE-2016-6210, an information disclosure vulnerability that lets you check whether a username exists on the target system.

Exploit: exploit-db.com/exploits/40136

CVE-2016-6210 Rabbit Hole

Remember the name we found in notice.txt? Maya. I thought it could lead somewhere. The plan was simple: confirm the username with this vulnerability, then brute-force my way in.

I fired up Metasploit and found the SSH username enumerator at scanners/ssh/ssh_enumusers. I set RHOST as the machine IP and hit run, but got an error straight away. I forgot to set USERNAME. I set it to Maya, hit run again, and got a false positive error. I then set CHECK_FALSE to false, hit run again, and it said USER MAYA FOUND.

Something felt off, so I tried the username rfvewbfibk. It also came back as FOUND. Now I knew something was wrong.

I went online and tried every CVE-2016-6210 exploit I could find. Nothing worked because of a bug in Python’s paramiko library. I tried Python virtual environments, forcefully installing requirements on main Python, everything. Still nothing.

At this point I let Gemini generate a custom exploit for it. I was confident. Hit enter. MAYA FOUND. Let’s go.

I cross-checked it with a random string as the username. Found again. False positives across the board. This time I chose not to fall into the same rabbit hole I did last time, debugging broken code I found online. I stepped back completely. No more SSH. Back to FTP.

The Real Way In: FTP Write Access

I started retracing my steps. How did I reach FTP? Did I miss anything? Any bug on the website? Any port I ignored? I read through the Nmap results again and saw it. Here are the results again. Do you see it?

The FTP directory is writable.

I logged back into FTP and uploaded two files to the /files/ftp directory:

• linpeas.sh
• A Pentest Monkey PHP reverse shell

I was confident PHP was installed since this was a web server. I started a Netcat listener, opened the browser, and clicked payload.php.

And I was in. Successful reverse shell. I navigated to the FTP directory and ran LinPEAS.

Finding Credentials in a PCAP

If you know what a Linux file system normally looks like, you will spot it immediately. There is an /incidents directory. That is not standard. I checked it and found a file called suspicious.pcapng. I downloaded it to my machine and opened it in Wireshark.

Lots going on. I tried filtering HTTP packets first but found nothing useful. I tried searching for passwords as strings but still nothing. Finally, I followed the TCP stream and that is where it all was.

There is a user named Lennie, and her password was captured in plaintext. I copied it and SSHed in immediately. User flag found.

Privilege Escalation: Writable Cronjob Script

Time to get the root flag. I explored Lennie’s files and a scripts folder caught my eye. Inside it was a script called planner.sh. I opened it and saw it executes another script at an unusual path: /etc/print.sh. That screamed cronjob to me.

I added a Bash reverse shell line to /etc/print.sh, saved it, and started a Netcat listener. About a minute later, the shell came back. Root flag found.

Key Takeaways

Thanks for reading. Happy hacking.

Disclaimer

This walkthrough is for educational purposes only. All activities were performed on legally authorised Hack The Box systems.

Initial Reconnaissance

I started with a basic Nmap scan to identify open ports and services:

nmap -sC -p- 10.129.3.175

While the scan was running, I checked if there was a website. Yes—there was a security dashboard running. I explored the site, read source code from different pages, tried logging out, but found nothing useful.

The most interesting page let users download a .pcap capture file.

.pcap Download Page → IDOR Vulnerability

I downloaded the file and checked for something valuable, but found nothing. Then I noticed the URL and experimented with it:

• Changing the value to 10 → nothing changed
• Changing it to 0 → access to another user’s capture data

This is a classic IDOR (Insecure Direct Object Reference) vulnerability.

I downloaded the other user’s .pcap file and analysed it in Wireshark. After scrolling through the traffic, I found the username and password transmitted in plaintext.

Credentials Extracted from PCAP

The protocol used was FTP. I checked my Nmap results (better image attached since I lost the original screenshot):

Open Ports: (FTP was one of them)

I logged in using the FTP credentials from Wireshark, and YEAH I WAS IN. I checked the user file and found the flag.

Privilege Escalation

Now I needed the root flag. I used Linpeas, a privilege escalation script:

• GitHub: PEASS-ng/linPEAS
• Official Website: linpeas.org — tons of free resources

I tried uploading it via FTP, but it failed due to a permission error.

Instead, I transferred the script over SSH and ran it from there. LinPEAS ran successfully and returned its findings.

LinPEAS Output → CVE-2021–3156

LinPEAS flagged CVE-2021–3156. I started reading about it and was confident it would work (I was so wrong).

What is CVE-2021–3156?

Also known as Baron Samedit, it’s a heap-based buffer overflow in sudo:

• Privilege-escalation bug in sudo
• Once you have local access, you can compromise the entire system
• Particularly serious since it’s in sudo

How it works:

1. When you run sudo in shell mode, it allocates memory to process your command
2. You give input ending with a single backslash (\)
3. sudo reads the backslash and skips to the next character, jumping over the “null terminator” (stop sign for text end)
4. Missing the stop sign, sudo blindly copies data past its boundaries into neighbouring memory blocks
5. This overwrites sudo’s internal settings, tricking the system into running malicious code with root privileges

I found an exploit online offering C and Python versions (in case C fails):

GitHub: worawit/CVE-2021-3156

I ran the C version first since the system met the requirements:

File successfully compiled. Let’s go. Now let’s run it.

It failed. Why? This exploit needs to write to /etc/passwd in a tiny window (milliseconds). The default timing (4000ms) wasn’t right. I tried:

• 2000 (faster) → failed
• 5000 (slower) → failed

All timings failed.

I switched to the Python version & Here’s what happened

The exploit says the vulnerability is patched. Now I had a choice: Either I debug further why the exploits aren’t working, or I look for another vulnerability because

• C exploit (race condition) — compiled fine, but race timing failed
• Python exploit (heap manipulation) — says target is patched

I decided not to waste time going deeper into the rabbit hole and started looking for another vulnerability.

The Real Vulnerability: Python cap_setuid Misconfiguration

Five minutes of re-reading the LinPEAS output, I spotted what I missed the first time Python had the cap_setuid capability set. This is a Linux capability to change your User ID to 0 (System ID / Root).

The Exploit Code

import os
os.setuid(0)
os.system('/bin/bash')

Running this gave me a root shell, and I found the root flag.

Key Takeaways

Thanks for reading. Happy hacking.

OverTheWire’s Natas wargame is a series of web security challenges that teach server-side vulnerabilities.

Prerequisites

What you should know:

• Basic HTML/CSS structure
• How to use browser developer tools
• Basic command line usage
• Understanding of HTTP requests (helpful but not required)

Tools you’ll need:

• A web browser (I used Chrome/Firefox)
• Burp Suite Community Edition (for intercepting HTTP requests)
• Python 3 (for decoding in Level 8)
• A text editor or terminal for running quick scripts

Natas Level 0

Authentication Credentials:
Username: natas0
Password: natas0
URL: http://natas0.natas.labs.overthewire.org

Upon visiting the website, we are asked for a username & password, which we already have, so we enter them as given.

After logging in, we see this page. There’s nothing here except a ‘Submit token’ button, which takes us outside the scope, so let’s check the source. On hitting Ctrl + U (View Source), we can see the password in line 16.

Natas Level 0 → Level 1

Authentication Credentials:
Username: natas1
URL: http://natas1.natas.labs.overthewire.org

Upon visiting the website, we are asked for Username & Password. We use the provided username and the password we got from the previous level. After logging in, we see this page.

Right-click is blocked on this page, but since we know shortcuts, we don’t need to worry. You can use any of the following:

Alternative methods to access developer tools:

• Ctrl + Shift + I : Opens the browser’s Inspect Element panel
• Ctrl + U : Displays the page source in a new tab

I used Inspect Element, and on Line 17, we can see the password.

Pro tip: For complex websites with extensive code, use Ctrl + Shift + I rather than Ctrl + U. The Inspect Element panel allows you to collapse and expand code blocks, making navigation much easier.

Natas Level 1 → Level 2

Authentication Credentials:
Username: natas2
URL: http://natas2.natas.labs.overthewire.org

Upon visiting the website, we are asked for username & password. We use the provided username and the password we got from the previous level. After logging in, we see this page.

Nothing again, so I view the source.

On Line 15, there’s a PNG image attached, so I clicked the image, and it was just a blank image. I thought this might have to do with image steganography, so I downloaded the image and decided to check for Exif information (metadata), but found nothing until I realized this entire challenge is related to web security, not image steganography. I went a step back and decided to see the source of the image, but found nothing. Then I went back one more step, and something caught my eye.

Can you see it? Take a guess.

We have the full file path of the image. I quickly reopened the image and removed the image portion from the link.

From:
http://natas2.natas.labs.overthewire.org/files/pixel.png

To:
http://natas2.natas.labs.overthewire.org/files/

I clicked the users.txt (http://natas2.natas.labs.overthewire.org/files/users.txt) and got the password.

Natas Level 2 → Level 3

Authentication Credentials:
Username: natas3
URL: http://natas3.natas.labs.overthewire.org

Nothing on the page, no password or image in the source code, but there’s a hint. Line 3 says:

This stuff in the header has nothing to do with the level

I fired up Burp Suite, checked the headers, and found nothing. I was confused. I went a step back and read the source code, and read Line 15, which I had ignored previously.

No more information leaks!! Not even Google will find it this time…

“Not even Google will find it this time” Hmmm, why can’t Google find it? What could it be? What is something on a website that Google can’t find?

Thought about it for a minute, then it clicked in my mind: robots.txt. That’s something Google can’t index. I fixed the link:

From:
http://natas3.natas.labs.overthewire.org/

To:
http://natas3.natas.labs.overthewire.org/robots.txt

We got it. The robots.txt is disallowing the /s3cr3t folder. Time to check it out, I changed the link again.

From:
http://natas3.natas.labs.overthewire.org/robots.txt

To:
http://natas3.natas.labs.overthewire.org/s3cr3t/

I clicked the users.txt (http://natas3.natas.labs.overthewire.org/s3cr3t/users.txt) and got the password.

Natas Level 3 → Level 4

Authentication Credentials:
Username: natas4
URL: http://natas4.natas.labs.overthewire.org

The website says Access Disallowed and gives us a hint. I load up Burp Suite and see the request over there, but I see nothing. Then I click the Refresh Page button provided on the site, and I see it.

This is an example of Referer-based access control. The site is checking if the request came from http://natas5.natas.labs.overthewire.org/ or not. We change the Referer part in the request.

From:
http://natas4.natas.labs.overthewire.org/

To:
http://natas5.natas.labs.overthewire.org/

Then we get the response we wanted. Check Line 24.

Natas Level 4 → Level 5

Authentication Credentials:
Username: natas5
URL: http://natas5.natas.labs.overthewire.org

Upon entering the username and password, we are greeted with this page. I checked the source code, and I see nothing.

I open Burp Suite, send the Request to the repeater and take a look at it, then I see it.

Line 12 gives away the answer:

Cookie: loggedin=0

Cookie here means the login status, and it is set to 0, which means False, so I changed it.

From:
Cookie: loggedin=0

To:
Cookie: loggedin=1

Then I sent the request and got the password in response.

Natas Level 5 → Level 6

Authentication Credentials:
Username: natas6
URL: https://natas6.natas.labs.overthewire.org

The page asks for a secret and includes a View Source Code button.

I click the View Source Code button, and we can see the following code.

Here we can see the PHP code of how authentication works. The script is importing an external file called secret.inc, so I quickly copied the path of the file and pasted it in the URL.

From:
http://natas6.natas.labs.overthewire.org/index-source.html

To:
http://natas6.natas.labs.overthewire.org/includes/secret.inc

Here we can see the secret.

Now, upon entering this secret in the input field, we will get the password.

Natas Level 6 → Level 7

Authentication Credentials:
Username: natas7
URL: http://natas7.natas.labs.overthewire.org

After logging in, I see this.

I click the Home Button and see its source (Ctrl + U). Line 21 gives us a clear hint:

– hint: password for webuser natas8 is in /etc/natas_webpass/natas8 –>

I changed the URL

From:
view-source:http://natas7.natas.labs.overthewire.org/index.php?page=home

To:
view-source:http://natas7.natas.labs.overthewire.org/index.php?page=/etc/natas_webpass/natas8

Now, we have the password to move further.

Natas Level 7 → Level 8

Authentication Credentials:
Username: natas9
URL: http://natas9.natas.labs.overthewire.org

We see this when logging in, I quickly press the View source code button given on the site.

The site’s source code looks like this. We can see a PHP script embedded in it. Let’s understand it.

Code Explanation:

• There’s a variable called encodedSecret that stores some value.
• There’s a function called encodeSecret() which takes the value of a variable called secret (not encodedSecret, don’t confuse it with the previous step’s variable). The secret value gets encoded in Base64, then it gets reversed, and at last it gets converted to Hexadecimal. This function just exists; it’s not being executed yet.
• The script checks if the user has clicked the submit button.
• If not clicked, then do nothing.
• If clicked, then take the value entered by the user, then pass it to the encodeSecret() function (STEP 2), where it gets converted.
• Compare the final converted output to the encodedSecret variable (STEP 1). If they match, then print Access Granted.

Now that we have understood the code, let’s reverse it. To reverse it, we have to do the following:

1. Convert the hex back to a string.
2. Reverse the string.
3. Decode the string from Base64 to its original value.

Instead of manually decoding all these strings online, I have written a small code for it in Python:

python3 -c 'import base64, binascii; print(base64.b64decode(binascii.unhexlify("3d3d516343746d4d6d6c315669563362")[::-1]).decode())'

This will give us the decoded secret, which is oubWYf2kBq. Now enter it as the secret and hit the submit button. You will get the password.

Natas Level 8 → Level 9

Authentication Credentials:
Username: natas9
URL: http://natas9.natas.labs.overthewire.org

After authenticating, we see this input field on the site. I decide to click the View source code button on the page.

An embedded PHP script that makes a query via passthru. Interesting!

Passthru is used to execute system commands. This script takes input from the user and directly gets it executed through passthru; there’s no input sanitisation, so let’s test if we can chain commands in it.

Command chaining means executing multiple commands in a single line using special operators. Here I used a semicolon to chain and put pwd to check if it’s working — and it worked. The command pwd prints the working directory, so now we can see where we are at right now. Let’s exploit this vulnerability now.

In level 7, the password was stored in /etc/natas_webpass/natas8, so I decided to check if the same folder exists or not.

Found it. Now we know where our password can be, so I tried this:

;cat /etc/natas_webpass/natas10

and got the password.

Natas Level 9 → Level 10

Authentication Credentials:
Username: natas10
URL: http://natas10.natas.labs.overthewire.org

Enter the username provided & password from the previous level.

Click View Source Code.

Hmm, they seem to have added input sanitisation now, but they missed one thing — they still use passthru. We can’t chain commands, but we can manipulate grep to do the work for us. We can do this by putting:

.* /etc/natas_webpass/natas11

as input, what this does is tell grep to read everything.

We got the password.

That is it for this walkthrough, I will upload the walkthrough of the next levels in the next write-up. Till then. Keep Hacking

What is a Keylogger?

A keylogger is a software or hardware tool that records your keystrokes as you type. It’s often used for malicious purposes. There are two main types:

⚠️ Disclaimer: This post is intended for educational and cybersecurity research purposes only. The techniques and code discussed are designed for controlled testing on systems you own or have explicit permission to work on. Unauthorized use of keyloggers is illegal and unethical. The author does not take responsibility for any misuse.

Initial Attempts

Recently, I wanted to test a keylogger on my own device to understand how it works, so I convinced ChatGPT to help me write one in Python. I ran the script, but it didn’t record any keystrokes.

After digging, I discovered the problem: the pynput library—a popular Python module for capturing keyboard events—doesn’t work properly with the Wayland display server. I tried debugging, but ran into another issue related to my desktop environment. I use KDE Plasma, and I wasn’t switching DEs just because of one error.

Looking for alternatives, I searched “keylogger linux download” on Google and found GitHub repositories. I picked one, cloned the repo, followed the README—and it failed again. I checked the code and spotted pynput being used there too. I made tweaks, still no luck. Frustrated, I sudo rm -rfed it.

(sudo rm -rf: Forcefully delete a directory and its content)

Cloned a new repo with new code and libraries—but the same compatibility issue. The project hadn’t been maintained for years. I gave up on others’ solutions and decided to write my own keylogger from scratch.

Design Overview

I outlined the basic features I wanted, focusing on core elements for an intermediate-level keylogger:

Keystroke Logging

I decided to use pynput because I was determined to get it running—and it’s the easiest to use.

Remote Access & Exfiltration

This was the most challenging part. Thinking from a SOC Team perspective, I wanted to exfiltrate data without triggering an IPS (Intrusion Prevention System). Some of the worst methods include:

• Email
• FTP
• SMB
• DNS Tunneling

Anti-Detection Mechanism

No interactive terminals or obvious signs of activity. Everything runs in the background in the least detectable way possible.

Self-Destruction & Persistence

Keystroke logs wouldn’t be saved permanently—they could grow and trigger alerts. The keylogger needed to function autonomously without leaving easily detectable traces.

First Attempt

After reading 2–3 tutorials and some documentation, my first keylogger was ready. It worked—but did it behave like malware or a rootkit from sketchy game/movie download sites? Not even close.

Problems:

• Pynput couldn’t capture keystrokes across multiple virtual desktops
• Keylogs stored directly in the home directory
• Exfiltration: plain text sent over HTTP to a random site

Yeah—this would get flagged and blocked in less than a second. I realized I needed to think like an actual malware developer, from coding style down to file naming.

I spent a day researching keyloggers properly: YouTube videos, GitHub code, blog posts, and ChatGPT for ideas. Now I knew what a keylogger is.

The Keylogger

I switched from pynput to evdev since evdev reads events directly from /dev/input and captures system-wide input, completely solving the virtual desktop capturing issue.

For exfiltration, I used the Telegram Bot API—it blends in with normal web traffic and uses encrypted HTTP requests. Captured data is sent directly to a Telegram channel. I got the idea from phishing pages; many use Telegram API to exfiltrate stolen data, so I knew it would be reliable.

The keylogger now stores keystrokes in /dev/shm/, a volatile directory (automatically cleared on reboot), and deletes the log file after sending it to Telegram.

Result:

• Runs quietly in the background
• Uses less CPU
• Avoids repeated requests that could trigger detection

PROJECT LINK

GitHub - 5odead/Trevent — A keyboard input monitoring and logging tool for cybersecurity research. Designed for Ethical Testing ⌨️

File Structure and Names for Full Stealth

Create a folder called networkd-helper in /usr/lib/systemd/:

mkdir -p /usr/lib/systemd/networkd-helper

Installation Path: /usr/lib/systemd/networkd-helper/

Names that mimic actual system files people won’t find suspicious.

Run Command (nohup to run in the background):

nohup sudo python3 FILENAME.py &

Notes

1. Set KEYBOARD_DEVICE to your actual event number—or the logger won’t capture anything.
2. Update CHAT_ID and BOT_TOKEN in your exfiltration script—or data won’t get sent.

Conclusion

The keylogger now uses some of the best tricks and strategies I’m aware of, but it still has flaws a blue team professional could easily detect.

For example, the process can be spotted effortlessly using ps aux. I’ll continue refining and improving it over time.

If you have questions, feel free to reach out or leave a comment.

What Tor Actually Does

Tor (The Onion Router) is a decentralized network of volunteer relays. Each relay encrypts your traffic and peels off a layer like an onion before forwarding it. The final relay—the exit node—delivers your request to the destination site.

Tor Browser is the ready-to-use package: it automatically sends all traffic through Tor, hides your IP, and blocks many tracking methods.

Why Exit Nodes Matter

Exit nodes don’t see your real IP, but they can see the destination site and the unencrypted contents of your traffic (unless the site uses HTTPS). Tor picks exits randomly by default, but you may want to control them for:

• Testing: Check how a site behaves from a specific country
• Research: Access region-restricted content
• Content access: Ensure traffic exits in a certain location

Edit torrc to Control Exits

Find your torrc file:

• Windows: C:\Users\<YourUsername>\AppData\Roaming\Tor\torrc
• macOS/Linux: /etc/tor/torrc or ~/.tor/torrc

Open it and add the lines below.

Pick a country

ExitNodes ua
StrictNodes 1

• Replace ua with a country code: us (USA), fr (France), de (Germany), etc.
• StrictNodes 1 forces Tor to only use exits in that country.
• Set StrictNodes 0 if you want Tor to prefer that country but allow others if needed.

Use multiple countries

ExitNodes us,de,fr
StrictNodes 0

Tor will prioritize exits in the US, Germany, and France, but can fall back to others.

Pin by IP address (optional)

ExitNodes 192.168.1.1
StrictNodes 1

Replace with the actual exit node IP you want.

Blacklist countries or nodes

Block as exit nodes only

ExcludeExitNodes ru,cn

Tor won’t use Russia or China as exits, but can still use them as entry/middle relays.

Block from the entire circuit

ExcludeNodes ru,cn

This prevents Tor from using those countries at any position (entry, middle, or exit).

Quick reference

References

1. Tor Project Documentation - Official guide for configuring and using Tor.
   • Tor Project Documentation
2. Tor Network Overview - Overview of how the Tor network operates.
   • Tor Network Overview
3. Country Codes - Snippets and codes available at:
   • Country List
   • Snippets

What They Actually Do

These tools don’t just hide your IP. They let you spoof metadata down to the font list on your device. Think of it like walking into a crowded market wearing a mask—and a fake name tag, a fake outfit, and a fake voice.

You can configure what the outside world sees:

• User agent string
• Operating system
• Screen resolution
• Installed fonts
• IP address (when paired with a proxy)

Notorious Tools in the Scene

Others worth noting: Nstbrowser, MoreLogin, Multilogin, GeeLark

How Hackers Use Them

Credential Stuffing

Attackers feed stolen username/password pairs into accounts while shifting fingerprints to avoid security flags. One batch of credentials can hit thousands of accounts without tripping detection.

Fraudulent Transactions

Stolen credit cards, identity theft, and fake purchases all happen behind a changed digital mask. The real identity stays hidden while the transaction goes through.

Scamming and Phishing

Fake websites imitate legitimate ones—bank portals, login pages, payment gateways. Anti-detect browsers let attackers host these sites and dodge law enforcement tracking.

Botting and Mass Account Creation

Social media, e-commerce, and gaming platforms get flooded with fake accounts. Reviews are manipulated, spam explodes, and markets get disrupted.

Data Harvesting

Websites get scraped for client lists, prices, emails, or private data without triggering anti-bot systems. The scraped data often ends up on the dark web or fuels targeted attacks.

The Bottom Line

Anti-detect browsers aren’t just privacy tools—they’re deception engines. They enable anonymity, but they also power fraud, phishing, botnets, and large-scale account abuse. As security systems tighten, these browsers evolve too, keeping the fight between protection and exploitation locked in a constant cycle.