Welcome back, aspiring cyberwarriors!

If you’ve spent any time hunting through vulnerability databases, you may have noticed a recurring trend involving a certain brand of budget networking gear. Tenda routers appear time and again, not because researchers have it in for the company, but because of persistent, systemic security failures that remain largely unaddressed. These issues have almost turned Tenda into a textbook example of what not to do when it comes to product security management.

In this article, we’ll explore the reasons behind Tenda’s notorious reputation, examine the modern threats posed by their devices, and dive into a practical lab to exploit one of their information-disclosure vulnerabilities. Let’s get rolling!

What is Tenda?

Tenda is a Chinese manufacturer of networking hardware, primarily recognized for offering budget-friendly equipment for home and small business networking. Their product lineup includes wireless routers, range extenders, network switches, and IP cameras.

At first glance, you might overlook Tenda as just a small Chinese company without significant influence. However, a quick search on Shodan reveals an entirely different story.

There are over 12,000 hosts that could potentially serve as gateways for both the Chinese government and hackers worldwide to access various networks.

Problem #1: A Culture of Silence

To understand the issues with Tenda, it’s essential to recognize a troubling pattern of behavior rather than focusing on a single vulnerability. When Carnegie Mellon’s CERT/CC identifies a significant backdoor in the firmware of several router models and reaches out to Tenda for a coordinated disclosure, one might expect a company of Tenda’s stature to acknowledge the issue and take steps toward a resolution. Unfortunately, that hasn’t been the case. CERT/CC’s recent advisory on this backdoor reveals that Tenda has remained silent since they were contacted in May 2026, with no patches released for any of the five affected router models.

This isn’t just a one-off incident. Back in 2020, researchers from Independent Security Evaluators discovered a hardcoded telnet password embedded in the Tenda AC15 AC1900. They notified the company and waited nearly double the standard 90-day disclosure period without receiving a response, ultimately publishing their findings without any acknowledgment from Tenda. If you look even further back to 2013, you’ll find a security researcher documenting a LAN-side backdoor in the Tenda W302R and W330R routers, which was also never patched. When a company remains unresponsive for over a decade and across multiple hardware iterations, it indicates a fundamental flaw in its business model rather than just a series of mistakes.

Problem #2: Hardcoded Credentials

The scale of Tenda’s problems becomes even clearer when looking at firmware analysis studies instead of individual disclosures. Research scanning extensive batches of Tenda firmware images has revealed that nearly one in five contain hardcoded default credentials or even empty passwords embedded directly in the binary. This isn’t a rare oversight; rather, it points to a recurring design choice made across an entire line of products. When you combine this statistic with a vendor that ignores security disclosures, it means Tenda is, in effect, distributing routers that come pre-loaded with vulnerable access points, easily exploitable by anyone who knows where to look.

Problem #3: The Backdoor that Makes Changing Your Password Meaningless

A particularly egregious example is CVE-2026-11405. This vulnerability deserves special attention due to the way it undermines the basic principles of router security. It resides within the login function of the httpd web server binary that runs on several router models. Typically, when a user submits a password, the router checks it using MD5-based verification. However, if this check fails, instead of simply rejecting the login attempt, the code unwittingly falls through to a second, undocumented authentication route. It retrieves a hidden configuration value called sys.rzadmin.password and directly compares it in plaintext to the password submitted by the attacker. If they match, the router grants administrative access at role level two, and critically, the username input during this attempt isn’t validated at all. This means that any username coupled with the correct backdoor password gains access.

Consider the implications for an average user who has followed all the right steps. You purchase the router, log into the web interface, and change the default admin password to a strong, unique one, just as every security guide advises. Unfortunately, none of that matters here since the backdoor password exists entirely outside the interface that you interacted with. It is stored in the device’s configuration, hidden from any user-facing menu and unaffected by any password changes you make through the regular admin panel. The only way to eliminate this risk is through a complete firmware rewrite from the vendor, and as of now, Tenda has provided no indication that such an update is forthcoming.

Problem #4: Crashing Devices Without Authentication

Backdoors aren’t the only serious vulnerability affecting this ecosystem. CVE-2026-36794 targets the Tenda W3 router and highlights a stack-based buffer overflow that an unauthenticated remote attacker can exploit simply by sending a specially crafted HTTP request.

There’s no need for a login or any user interaction; the attacker just requires network access to the device’s web interface. The consequence is a device crash, leading to a straightforward denial of service.

Practical Lab: Pulling Credentials Out of the Tenda N300

Now, let’s dive right in. While the recent backdoor vulnerability we discussed is certainly eye-catching for 2026, today we will focus on an older issue: CVE-2020-35391, which affects the Tenda N300. I have chosen this example intentionally, as it highlights a troubling trend within Tenda, specifically the consistent shipping of exploitable authentication flaws.

The issue lies in how the router manages configuration backup requests. Normally, an authenticated administrator can easily request a copy of the device’s configuration file for backup by accessing an endpoint at cgi-bin/DownloadCfg/RouterCfm.cfg. The problem arises because this endpoint fails to properly enforce authentication before releasing the file. An attacker can simply send a direct request to that endpoint and sometimes gain access to the complete configuration file. Once you have that configuration file, open it up and find the line labeled extend_pass.

That single line contains the administrative password for the router’s web interface, made accessible without any login credentials. From here, exploiting this vulnerability is straightforward. Just take that password, navigate to the router’s usual login page, and authenticate as the administrator. You will then have full control over the device, including its DNS settings, port forwarding rules, and every device connected behind it.

Summary

These days, Tenda hardware remains quite popular in various countries due to its affordability. However, we must be more cautious about security, as overlooking it could lead to significantly higher long-term costs.

If you’re interested in exploring how to both attack and secure routers, consider enrolling in the VPN & Router Hacking course. This course delves into router exploitation through manual RCE (Remote Code Execution), information disclosure, and unauthorized code execution on devices like Netgear, Netis, and Telesquare, as well as enterprise-grade systems like FortiPAM and FortiSwitchManager – and much more.

The post Router Hacking: Why the World’s Most Popular Budget Router Keeps Making Headlines for the Wrong Reasons first appeared on Hackers Arise.

Welcome back, my aspiring cyberwarriors!

One of the most critical skills any hacker must master is understanding the operating system they work within. Linux sits at the foundation of nearly every penetration testing distribution, serves as the backbone of most servers you’ll encounter in the field, and provides the power and flexibility that cannot be found in consumer operating systems like Windows or macOS. Without solid Linux skills, the world of hacking remains a largely closed door. And yet, Linux is vast.

There are layers upon layers of knowledge to acquire, from basic navigation to advanced scripting and privilege escalation techniques. Each piece builds upon the last, creating a foundation that separates those who can merely run tools from those who truly understand what they’re doing under the hood.

In this tutorial, we will examine one of the fundamental security mechanisms built into every Linux system: file permissions. Linux implements a robust permission system that controls exactly who can read, write, and execute any file or directory on the system. Understanding these permissions lets you control who can access, modify, or run your files. More importantly for us as cyberwarriors, understanding these permissions reveals how systems protect themselves and, crucially, where those protections might fail or be misconfigured, leaving them vulnerable to exploitation.

Step 1: Checking Permissions

To view a file’s permissions, use the ls command with the -l (long) switch. Let’s use that command in the /usr/share/hashcat directory and see what it tells us about the files there.

First, let’s navigate to its directory.

kali > cd /usr/share/hashcat

Then, list its directory in detail.

kali > ls -l

If we look at each line, we can see quite a bit of information on the entries in this directory, including:

(1) whether it’s a file or directory,
(2) the permissions on the file,
(3) the number of links,
(4) the owner of the file,
(5) the group owner of the file,
(6) the size of the file,
(7) when it was created or modified, and finally,
(8) the name of the file.

Let’s examine each of these.

Identifying a File or Directory

The very first character of the line tells us whether it’s a file or a directory. If the line begins with a “d”, it’s a directory. If it begins with a “-“, it’s a file.

Identifying the Permissions

The next section of characters defines the file’s permissions. Three sets of rwx stand for read, write, and execute. This determines whether there is permission to read, write, or execute the file. Each set of rwx represents the permissions for the owner, the group, and all others, respectively.

So, let’s look at the hashcat rules directory (hashcat rules transform your wordlist so it may better fit the target password, including the combinator.rule, which changes capitalization, such as occupytheweb -> OccupyTheWeb).

Let’s navigate to the rules directory and then do a long listing.

kali > cd rules
kali > ls -l

We can see that each begins with:

-rw-r–r–

This means it’s a file (-) with read (r) and write (w) permissions, but no execute (x) permission. Note, here the dash “-” represents nothing or no permission.

The next set of permissions represents the group’s permissions. Here, we can see that the group has read (r) permissions but not write (-) or execute (-).

Finally, the last set of permissions is for all others. We can see that all others have only the read (r) permission on these files.

Step 2: Changing Permissions

Let’s imagine a case where we wanted the group to be able to write to the hashcat combinator.rule file. Someone in the group has developed an improvement to this rule and wants to write the changes and share them with the rest of the group.

Linux has a command called chmod (change mode) that allows us to change the permissions on a file, as long as we’re root or the file’s owner. These permissions are represented by their binary equivalents in the operating system.

Permissions by the Numbers

Remember, everything is simply zeros and ones in the underlying operating system, and these permissions are represented by on/off switches in the system. So, if we imagine the permissions as three on/off switches, and these switches use the base-2 number system, the far-right switch represents 1 when on, the middle switch represents 2 when on. The far-left switch is on when 4 is displayed.

So, the three permissions look like this when they are all on:

r w x
4 2 1 = 7

If you sum these three, you get seven. In Linux, when all the permission switches are on, we can represent it with the decimal numerical equivalent of 7. So, if we wanted to represent that the owner (7), the group (7), and all users (7) had all permissions, we could represent it as:

777

Now, let’s go back to our hashcat combinator.rule file. Remember its permissions? They were rw-r–r–, so we could represent that numerically like:

r w – | r – – | r – –
4 2 0 | 4 0 0 | 4 0 0

This can be represented by 644.

Changing the Actual Permissions of combinator.rule

Now, if we wanted to give the group write (2) privileges, we can use the chmod command to do it. We need to add the write (2) privilege to the combinator.rule file. We do that by:

kali > sudo chmod 6 6 4 combinator.rule

This statement says give the owner read and write permissions (4+2=6), the group the same (4+2=6). and give everyone else read permission (4 + 0 + 0 = 4).

When we now do a ls -l, we can see that the permissions for combinator.rule are now:

r w – r w – r – –

Simple.

Step 3: Changing Permissions with UGO

Although the numeric method is probably the most common way to change permissions in Linux (every self-respecting Linux guru can use it), there’s another method that some people find easier to work with. It’s often called the UGO syntax. UGO stands for U=user or owner, G=group, and O=others. UGO has three operators:

+ for adding a permission

– to subtract a permission

= to set a permission

So, if I wanted to subtract the write permission from the group that the combinator.rule belongs to, I could write:

kali > sudo chmod g-w combinator.rule

This command says “for the group (g) subtract (-) the write (w) permission to combinator.rule.”

You can see that when I now check file permissions by typing ls -l, that the combinator.rule file no longer has write permission for the group.

If I wanted to give back the group write permission, I could type:

kali > sudo chmod g+w combinator.rule

This command says “for the group adds the write permission to the file combinator.rule.”

Step 4: Giving Ourselves Execute Permission on a New Hacking Tool

Very often, as hackers, we need to download or create new hacking tools. After we download, extract, unzip, build, and install them, we’ll often need to grant ourselves permission to execute them. This doesn’t happen automatically. If we don’t, we usually get a message that we don’t have sufficient permissions to execute.

We can see in the screenshot above that our newhackertool does not have execute permission for anyone.

When we do a long listing on our newhackertool, we can see that the permissions are only read and write (6) for the owner.

kali > ls -l

We can give ourselves (root user) permission to execute on a newhackertool by writing:

kali > chmod 766 newhackertool

As you now know, this would give us–the owner–all permissions, including execute, and the group and everyone else just read and write permissions (4+2=6). You can see in the screenshot above that after running the chmod command, we get exactly what we expect!

-rwx rw- rw--rwx rw- rw-

Summary

The article focuses on managing file permissions in Linux. We tried to explain how to check permissions using the ls -l command and how to interpret its output, which includes file types, permissions, ownership, and size. The article also discusses changing permissions with the chmod command and introduces numerical representations of permissions. Overall, it equips readers with foundational knowledge to manage file security and identify vulnerabilities in Linux systems.

For more information on using Linux for hacking, check out the book “Linux Basics for Hackers” on Amazon or visit our training center.

The post Linux Basics for Hackers, Part 06: Managing File Permissions first appeared on Hackers Arise.

Welcome back, aspiring cyberwarriors!

Open Source Intelligence, or OSINT, is a powerful yet underrated cybersecurity discipline. A solid reconnaissance phase uncovers vast target information before active probing even begins.

Traditionally, effective OSINT was a painful process. It meant juggling fragmented tools and manually parsing disjointed data to map a target. AI can completely automate this workflow. It calls the right tools in order and explains its analytical reasoning.

This article explores OpenOSINT, an automated intelligence agent built for security researchers. We will install the framework and test its core capabilities using real commands. Let’s get rolling!

What is OpenOSINT?

OpenOSINT is an artificial intelligence assistant designed to automatically gather public information and conduct digital investigations. To interact with OpenOSINT, you can choose from four different methods depending on your comfort level with computers. Beginners will likely prefer the web interface. For those who prefer working with text, the tool offers an interactive terminal. There is also a direct command line interface for running quick commands. Finally, it can act as a background server using MCP that plugs directly into other AI applications, like Claude Desktop.

The way this AI works makes it super reliable and gets rid of that annoying problem of AI making stuff up. When we ask OpenOSINT to do something, it connects to an AI engine. If the AI realizes it needs to look something up, it totally pauses and waits. Your computer then boots into tools, runs the actual program it needs, gathers the right info, and sends that back to the AI. Because the model has to wait for real results instead of just guessing, it can’t fake or invent any findings (or at least will do that less often).

If OSINT is a skill you want to develop seriously, we strongly encourage you to check out the dedicated OSINT series. It covers passive and active reconnaissance techniques, social media intelligence, geolocation, and much more, all taught by practitioners who do this work professionally.

Step 1: Installing OpenOSINT

Let’s clone and install the framework.

kali > git clone https://github.com/OpenOSINT/OpenOSINT.git

kali > cd OpenOSINT

From the observation of the source file, we can confirm that it’s a Python project. Our next step should be the installation of dependencies. Before that, it’s wise to create a dedicated virtual environment.

kali > pip install -e .

The command above uses the -e flag to install the package in editable mode. This means that any changes we make to the source files will be reflected immediately without the need to reinstall the package.

Next, we will install the external dependencies for OpenOSINT. Each dependency supports a specific investigation module, and the framework will still function properly even if some dependencies are missing. Holehe is used for email account enumeration, while Sherlock conducts username enumeration across more than 300 platforms. Sublist3r is utilized for subdomain enumeration. Installation is simple and can be done easily using pip.

kali > pip install holehe

kali > pip install sherlock-project

kali > pip install sublist3r

Another important tool for OpenOSINT is PhoneInfoga. It’s distributed as a standalone binary rather than a Python package, so download the latest release for your architecture from its GitHub releases page.

kali > tar -xzf phoneinfoga_Linux_x86_64.tar.gz

kali > sudo mv phoneinfoga /usr/local/bin/

Step 2: Configuring API Keys

OpenOSINT becomes significantly more effective when supplemented with additional information from external tools like VirusTotal. This integration allows OpenOSINT to gain a clearer understanding of the situation and ultimately make better decisions.

To configure the API keys, we need to open the .env file:

OpenOSINT supports a wide range of services. In this instance, I will specify my Anthropic API, VirusTotal, and Censys.

Step 3: Testing OpenOSINT Web Mode

OpenOSINT offers several ways to use its features. One of them is the AI REPL (Read-Eval-Print Loop), which is a simple, interactive programming environment that accepts user inputs, executes them, and returns the results. Another option is through the web interface, which I will use. There is also a direct tool usage method, but since it does not involve AI, I will not focus on it here, as we can use those tools directly without OpenOSINT.

To start the OpenOSINT web server, use the following command:

kali> openosint web

This command will open a webpage that looks like the one shown below.

Let’s start with a username investigation.

First, the system initiated a broad tool-based check across numerous platforms, returning raw data showing specific profile URLs for the username “tomilov” on sites ranging from Audiojungle and Behance to Codeforces and Discord, indicating presence on creative, social, and gaming platforms.

Finally, it synthesizes these findings into points, such as the subject’s probable Russian origin and their clear professional background. Essentially, the tool executed a digital footprinting task and transformed the results into categorized intelligence.

Next, let’s investigate a domain.

As shown in the screenshot above, the tool initiated its workflow by pulling WHOIS registration data, which fetched the registrar, the creation date from 2009, and the owning organization, LLC KUPISHUZ. At the same time, it performed a subdomain enumeration scan to map out associated hosts and queried VirusTotal to check the domain’s reputation against multiple security vendors.

The system then processed this raw data into a structured intelligence report. It verified that the domain possesses a long-standing, 14-plus year history with no malicious detections on VirusTotal. It also classified the discovered subdomains into operational roles, identifying specific functions such as a main website, a careers portal, internal networking infrastructure, an order tracking portal, and a Single Sign-On authentication platform.

Now, let’s test the email module.

This tool initiated its workflow by running an email enumeration scan using a utility called Holehe, checking the address across 121 websites. This initial check successfully verified active account registrations on Amazon, Flickr, Gravatar, Office365, and Twitter. During this phase, the tool also attempted to query breach data, paste sites, and search engine footprints, but these background tasks failed.

Following the raw scans, the tool generated a series of pre-configured Google dork links targeted at finding the email or username on LinkedIn, Twitter, and Facebook. The system then compiled these results into an Investigation Summary, detailing the discovered platforms and extracting specific metadata, such as the full name and profile URL linked to the target’s Gravatar account.

Finally, the tool outlined a set of next steps for a manual investigator.

Now, let’s run automated open-source intelligence investigation on the specific IP address.

The single successful data extraction came exclusively from the VirusTotal module. This integration successfully returned infrastructure information revealing that the IP address belongs to a network block managed by Senko Digital LLC, which operates as a hosting or virtual private server provider located in Germany. More importantly, the tool retrieved threat assessment telemetry showing that twelve distinct security engines explicitly flagged this specific IP address as malicious, while one categorized it as suspicious, forty-six marked it clean, and thirty-two left it undetected.

Based entirely on this VirusTotal telemetry, the tool synthesized the findings into a security alert status. It concluded that the infrastructure carries a high risk because it is hosted by a VPS provider commonly leveraged for anonymity and possesses a high detection rate across reputable security vendors.

Summary

OSINT remains one of the most high-leverage skills in the cybersecurity field, and tools like OpenOSINT that bring AI-driven automation to the reconnaissance phase will only become more effective and beginner-friendly. If you want to develop your OSINT skills from first principles alongside hands-on tool training, make sure to check out the OSINT Training and join the growing community of intelligence practitioners.

The post Artificial Intelligence (AI) in Cybersecurity, Part 22: Grounding OpenOSINT with Real Tool Execution to Prevent AI Hallucinations first appeared on Hackers Arise.