Post cover image

August 6, 2026

From an SSL Pivot to an ISP: Discovering a Large-Scale SNMP Exposure in PT Mega Data Akses (Mada)

While performing routine reconnaissance against an unrelated target, I unexpectedly discovered a large-scale SNMP exposure affecting…

By Ahmed Embaby

11 min read

بِسْمِ اللَّهِ الرَّحْمَٰنِ الرَّحِيمِ،
وَالصَّلَاةُ وَالسَّلَامُ عَلَى النَّبِيِّ الْمُجَاهِدِ الشَّهِيدِ،
اللَّهُمَّ انصُرْ أَهْلَ غَزَّةَ وَفِلَسْطِينَ وَالسُّودَانَ، وَطَهِّرِ الْأَقْصَى مِنْ دَنَسِ الْيَهُودِ،
أَمَّا بَعْدُ

While performing routine reconnaissance against an unrelated target, I unexpectedly discovered a large-scale SNMP exposure affecting multiple MikroTik routers belonging to PT Mega Data Akses (Mada), an Indonesian ISP.

The infrastructure exposed SNMP v2c using the default public community string, allowing unauthenticated access to operational metadata including routing information, interface descriptions, internal addressing, device inventory, software versions, and subscriber-related information. Over 95 subscriber sessions were enumerated from a single device.

Although the issue did not directly provide code execution, it significantly increased an attacker's reconnaissance capabilities by exposing the ISP's internal architecture and operational intelligence.

This write-up documents the discovery process, technical analysis, responsible disclosure timeline, and the lessons learned throughout the engagement.

1. Introduction

Sometimes the most interesting security findings are not the ones you're actively looking for.

This research started during a routine reconnaissance exercise against a completely different target. My objective had nothing to do with Internet Service Providers (ISPs), and I certainly wasn't expecting to discover a large-scale infrastructure exposure that would reveal the inner workings of a regional Indonesian ISP.

Like many reconnaissance workflows, I was collecting publicly available information subdomains, SSL certificate transparency records, DNS information, and infrastructure metadata. During one of those pivots, I noticed an SSL certificate that appeared unrelated to my original target. The certificate's Subject Alternative Names (SANs) pointed toward infrastructure that, upon further investigation, belonged to PT Mega Data Akses (Mada), an Indonesian Internet Service Provider operating primarily in the Riau province.

Curiosity led me to investigate further.

That decision ultimately revealed a publicly accessible network infrastructure that was exposing far more information than any organization would knowingly permit.

What initially appeared to be a routine service exposure quickly evolved into a detailed, near-complete view of the provider's operational network. Within hours, I had mapped their internal architecture, identified management systems, enumerated subscriber sessions, and cataloged software versions all without ever authenticating to a single device.

At first, I thought I had simply stumbled across another misconfigured device. But every SNMP query revealed another layer of the infrastructure. Interface names became regional links. Routing tables exposed backbone architecture. Subscriber sessions appeared one after another. At some point, I stopped thinking of it as "another finding" and realized I was looking at the operational view of an ISP's network.

That was the moment I shifted my mindset from vulnerability research to responsible disclosure.

2. Background: Understanding SNMP

Before diving into the technical findings, it's worth briefly explaining the protocol at the center of this exposure.

What is SNMP?

The Simple Network Management Protocol (SNMP) is a standard protocol designed for managing and monitoring network devices. It allows administrators to query devices for operational statistics, configuration information, and performance metrics.

The Problem with Community Strings

SNMP v1 and v2c use community strings as shared secrets that function like passwords. The two most common default community strings are:

  • "public" — typically used for read-only access
  • "private" — typically used for read-write access

When devices are configured with these default values and exposed to the Internet, they effectively grant unrestricted read access to the device's Management Information Base (MIB) — a hierarchical database containing operational parameters and statistics.

This is exactly what was observed in Mada's infrastructure.

3. Initial Discovery: The SSL Pivot

3.1 The Certificate That Started Everything

The discovery began with SSL certificate transparency logs. Certificate Transparency (CT) is a public logging system that records all SSL/TLS certificates issued by Certificate Authorities. While CT logs exist for security purposes, they are also an invaluable resource for security researchers and attackers alike.

I was reviewing CT logs for an unrelated domain when I noticed an SSL certificate with unusual SANs. The certificate appeared to cover multiple subdomains, some of which used naming conventions typically associated with ISP infrastructure.

Certificate Common Name: [redacted]
SANs:
  - mail.[redacted].com
  - webmail.[redacted].com
  - [other subdomains]

3.2 Initial Footprinting

Following the certificate lead, I performed initial service discovery against the associated IP ranges. A quick UDP scan revealed something interesting — multiple hosts responded on UDP port 161, the default SNMP port.

nmap -sU -p 161 103.14.x.x/24

Results: 25+ hosts responded on UDP port 161.

Testing confirmed that multiple devices accepted the default read-only community string "public":

snmpwalk -v2c -c public 103.14.x.x system

The devices responded with system information, confirming the exposure.

At that point, it became clear this was not an isolated device with a simple configuration oversight — it represented a broader infrastructure exposure spanning multiple network segments and device types.

4. Network Topology Mapping

4.1 Interface Enumeration

One of the most valuable pieces of information exposed through SNMP was the interface description table. Although interface names may appear harmless, they often reflect how engineers organize production environments.

Command:

snmpwalk -v2c -c public 103.14.x.x .1.3.6.1.2.1.2.2.1.2

OID Reference:

  • .1.3.6.1.2.1.2.2.1.2 — ifDescr (Interface Description)

Results (Partial):

text

Management Interfaces:
  - MGMT-VLAN-01
  - MGMT-VLAN-02
  - MGMT-CORE
Metro/Ethernet Links:
  - Metro-Link-RegionA
  - Metro-Link-RegionB
  - Metro-Link-RegionC
Peering/Transit Connections:
  - Peering-ProviderA
  - Peering-ProviderB
  - Peering-ProviderC
  - Transit-Upstream-01
Service Interfaces:
  - DNS-Service
  - Monitoring-Ping
Multicast Infrastructure:
  - Multicast-RegionA
  - Bridge-Multicast
  - Multicast-RegionB
Physical Interfaces:
  - SFP_1 through SFP_8
  - ether1 through ether4
Tunnels:
  - EOIP-Tunnel-IPv6

4.2 Geographic Inference

The naming conventions immediately revealed geographic information. While specific locations have been redacted in this write-up, the interface descriptions clearly identified multiple regional sites, suggesting a distributed infrastructure across several regencies.

4.3 Partner/Peering Relationships

Interface descriptions also exposed business relationships with multiple upstream providers and peering partners. This information is valuable to attackers because:

  1. It identifies trusted partner relationships (potential for supply chain attacks)
  2. It reveals transit providers (potential for BGP hijacking)
  3. It maps the ISP's upstream connectivity

5. Internal Address Disclosure

5.1 IP Address Enumeration

Further enumeration exposed numerous internal network addresses, including private RFC1918 ranges and management IPs.

Command:

snmpwalk -v2c -c public 103.14.x.x .1.3.6.1.2.1.4.20.1.1

OID Reference:

  • .1.3.6.1.2.1.4.20.1.1 — ipAdEntAddr (IP Address Entry)

Results:

Internal Management & Infrastructure:
  10.10.102.x
  10.10.115.x
  10.175.83.x
  172.16.16.x          <-- Primary aggregation point
  192.168.100.x
  192.168.127.x
  192.168.200.x
  192.168.80.x
Public-Facing:
  103.14.x.x
  103.14.x.x
  103.14.x.x
  103.14.x.x
  103.14.x.x
  103.14.x.x
Partner/Peering:
  103.134.185.x
  103.209.184.x

5.2 Risk Analysis

While internal IP addresses cannot typically be reached directly from the Internet, disclosing them provides attackers with valuable situational awareness:

  1. Lateral Movement Planning: If an attacker gains access through another vector, knowledge of the internal addressing scheme significantly reduces the effort required for lateral movement.
  2. Network Segmentation Understanding: The distribution of IP addresses reveals how the network is segmented (management, subscriber, infrastructure).
  3. Critical Asset Identification: IPs like 172.16.16.x clearly indicate core infrastructure — a prime target for advanced attacks.

6. Routing Intelligence

6.1 Routing Table Extraction

SNMP also exposed routing information, making it possible to understand how different parts of the provider's infrastructure were interconnected.

Command:

snmpwalk -v2c -c public 103.14.x.x .1.3.6.1.2.1.4.21.1.1

OID Reference:

  • .1.3.6.1.2.1.4.21.1.1 — ipRouteTable

Results:

Next-Hop Analysis:
  172.16.16.x           <-- Primary aggregation/route reflector
  192.168.100.x         <-- Regional aggregation
  192.168.127.x         <-- Regional aggregation
  192.168.200.x         <-- Regional aggregation

6.2 Core Aggregation Point

The concentration of routes toward 172.16.16.x revealed a highly centralized routing architecture. This single point of failure insight would be valuable to any adversary planning a disruptive attack.

7. Infrastructure Inventory

7.1 MikroTik Vendor MIB Enumeration

Vendor-specific MikroTik Management Information Base (MIB) objects revealed additional inventory information.

Command:

snmpwalk -v2c -c public 103.14.x.x .1.3.6.1.4.1.14988.1.1.11

OID Reference:

  • .1.3.6.1.4.1.14988 — MikroTik Enterprise OID

Results:

Connected Devices:
  192.168.100.x
  192.168.127.x
  192.168.200.x
  192.168.80.x
MAC Addresses:
  2C:C8:1B:44:XX:XX
  E4:8D:8C:B3:XX:XX
  20:65:8E:93:XX:XX
  24:A4:3C:78:XX:XX
Versions identified during enumeration:
  6.49.7
  6.39.3
  6.49.15
  XM.v5.6.6
Device Names:
  Backbone-Router-01
  Regional-POP-01
  Aggregation-Router-01
  Regional-POP-02

7.2 Version Disclosure Risk

Version disclosure is particularly important because attackers routinely correlate software versions against publicly known vulnerabilities. Some of the observed versions had publicly documented security advisories or CVEs available at the time.

Even without exploiting anything directly, this significantly simplifies target prioritization for an attacker. The mere availability of version information allows an adversary to:

  1. Identify potentially vulnerable systems
  2. Match CVEs to specific devices
  3. Prioritize targets based on exploit availability
  4. Reduce reconnaissance time in the attack lifecycle

7.3 ARP Table Disclosure

Command:

snmpwalk -v2c -c public 103.14.x.x .1.3.6.1.2.1.4.22.1.2

Results:

192.168.200.x -> 20:65:8E:93:XX:XX
192.168.100.x -> F4:FB:B8:B3:XX:XX

Risk: ARP table disclosure enables ARP spoofing attacks and device tracking, potentially allowing attackers to intercept traffic within the network.

8. Subscriber Exposure & Privacy Implications

8.1 PPPoE Subscriber Enumeration

One of the most concerning observations involved PPPoE-related information. Interface descriptions associated with subscriber connectivity demonstrated that customer-facing operational information could be inferred through SNMP responses.

Command:

snmpwalk -v2c -c public 103.14.x.x .1.3.6.1.2.1.2.2.1.2

Results (Sample):

pppoe-school-01           <-- Educational institution
pppoe-school-02           <-- Educational institution
pppoe-health-center       <-- Healthcare facility
pppoe-health-clinic-01    <-- Healthcare facility
pppoe-government-office   <-- Government entity
pppoe-village-office      <-- Government entity
pppoe-mosque-01           <-- Place of worship
pppoe-mosque-02           <-- Place of worship
pppoe-business-01         <-- Commercial entity
pppoe-customer-01         <-- Individual subscriber
pppoe-customer-02         <-- Individual subscriber
pppoe-customer-03         <-- Individual subscriber

95+ individual subscriber sessions were enumerated from a single device.

8.2 Privacy Impact

The PPPoE session names map directly to real-world entities, exposing Personally Identifiable Information (PII):

  • Educational institutions — schools and universities
  • Healthcare facilities — clinics and health centers
  • Government offices — identified by function
  • Places of worship — mosques and prayer rooms
  • Business entities — commercial and professional services
  • Individual subscribers — identified through naming patterns

This represents a violation of subscriber privacy, as their association with the ISP and their specific service locations are exposed to anyone with network access.

8.3 Traffic Monitoring

Command:

snmpwalk -v2c -c public 103.14.x.x .1.3.6.1.2.1.2.2.1.10.15841385

Results:

Counter32: 607391546 bytes (~579 MB)

Risk: Byte counters allow detailed monitoring of subscriber activity patterns. This could be used to:

  1. Identify high-value targets (high-traffic subscribers)
  2. Profile user behavior (when they are active, data patterns)
  3. Correlate with other intelligence for targeted attacks

9. Root Cause Analysis

The root cause was not a software vulnerability within MikroTik RouterOS itself, but rather an insecure operational configuration.

The devices were functioning exactly as configured — they were simply configured insecurely. No zero-day exploitation was required. No advanced techniques were necessary. The exposure existed because multiple security best practices were simultaneously ignored:

FactorContributionSNMPv2cPlaintext protocol with no encryptionDefault Community"public" is well-known and easily guessedInternet ExposureDiscoverable from anywhereLack of ACLsNo access restrictionsExcessive MetadataOverly descriptive naming exposing sensitive informationNo Regular AuditsConfiguration not reviewed for security

The Cascade Effect

No single misconfiguration caused this exposure it was the combination of all these factors. If any one of them had been addressed, the impact would have been significantly reduced:

  • SNMPv3 alone would have prevented unauthenticated access
  • Changing the community string would have made discovery harder
  • Firewall rules would have limited the attack surface
  • Reduced metadata would have minimized exposure value
  • Regular audits would have caught the issue earlier

This is why defense-in-depth is essential: relying on any single security control is never enough.

10. Why This Discovery Felt Different

Most security findings eventually become another report in a folder.

This one didn't.

It started with an SSL certificate that wasn't even related to the target I was researching.

It continued with what appeared to be a routine SNMP exposure.

Then the scale became clear.

I wasn't looking at a single router.

I was looking at an ISP.

Every SNMP response exposed another piece of the puzzle:

  • backbone routers
  • management VLANs
  • regional POPs
  • peering links
  • routing tables
  • subscriber sessions
  • internal infrastructure

At that point, the technical challenge became secondary.

The real question became:

How do I make sure this reaches the right people?

That question ultimately led me to Shadowserver Foundation and introduced me to an entirely different side of cybersecurity one focused not on finding vulnerabilities, but on helping get them fixed.

Looking back, that experience probably taught me more about responsible disclosure than the vulnerability itself.

11. Why This Matters

11.1 The Reconnaissance Advantage

Unlike traditional software vulnerabilities, this issue did not provide remote code execution. Instead, it enabled something equally valuable from an attacker's perspective:

Visibility.

Information disclosure is often underestimated because it does not immediately compromise a system. In practice, however, reconnaissance frequently determines the success of every subsequent attack phase.

An attacker performing reconnaissance could potentially use publicly available SNMP information to:

  1. Build an accurate network map
  2. Identify critical infrastructure
  3. Locate management networks
  4. Discover software versions
  5. Prioritize future attack paths
  6. Better understand the provider's architecture before attempting any intrusion

11.2 The Reality of Modern Attacks

In many real-world attacks, reconnaissance is the longest and most important phase. Attackers spend weeks or months gathering intelligence before they ever attempt to exploit a vulnerability. Reducing information exposure directly limits an attacker's advantage.

11.3 The PR & Reputation Risk

For an ISP, a security exposure of this nature carries significant reputation risk. Subscribers trust their ISP to protect their privacy and ensure service availability. If attackers can deanonymize subscribers through SNMP metadata, that trust is fundamentally broken.

12. Responsible Disclosure Timeline

Day 0 — An Unexpected Discovery

While performing reconnaissance against an unrelated target, I unexpectedly came across infrastructure that belonged to PT Mega Data Akses (Mada) .

During a routine review of the exposed services, I discovered that multiple MikroTik devices were publicly exposing SNMP v2c using the default public community string. After performing limited verification to understand the scope, it became clear that this was not an isolated device but a broader infrastructure-wide misconfiguration.

At that point, I stopped further enumeration and shifted my focus toward responsible disclosure.

Day 1 — Initial Disclosure

I prepared a detailed technical report describing the issue, its potential impact, supporting evidence, and remediation recommendations.

The report was submitted directly to PT Mega Data Akses (Mada) through their available security contact.

After submitting the report, I waited for a response while avoiding any additional interaction with the affected infrastructure.

Following Days — Looking for Another Way

After several follow-ups, I still hadn't received a response from the organization.

Rather than assuming the report had been ignored, I started looking for another responsible way to ensure the information reached the right people.

During that search, I came across Shadowserver Foundation, a nonprofit organization that works closely with network operators, ISPs, CERTs, and security researchers to coordinate responsible disclosure and Internet-wide remediation efforts.

Given their long history of assisting Internet Service Providers, I reached out to them and explained the situation.

Shadowserver Gets Involved

Until that point, I had never interacted with Shadowserver Foundation.

After multiple attempts to reach the ISP directly, I started looking for organizations that specialized in coordinated vulnerability disclosure.

That's when I found Shadowserver.

I explained what I had found, shared the technical details, and asked whether they could assist in notifying the ISP through their existing relationships.

Barry Greene replied almost immediately.

Instead of focusing only on the vulnerability itself, he commented on something that meant even more to me:

"I was impressed by the workflow and keeping to responsible disclosure."

He then invited me to become part of Shadowserver's trusted researcher community.

During our conversation, Barry asked whether I already had a PGP key.

I didn't.

He explained that although many researchers now communicate using Signal, maintaining a persistent PGP identity is still valuable because it provides a long-term cryptographic identity that organizations can trust.

That conversation encouraged me to create my first OpenPGP key and establish a verifiable researcher identity.

After sharing the public key with him, he welcomed me into their researcher records.

A short time later, Barry shared an article published on Senki describing how independent researchers can leverage Shadowserver for coordinated disclosure.

To my surprise, my own disclosure process had already been included as one of the examples.

Seeing my own experience documented there was something I genuinely wasn't expecting.

Remediation

Through Shadowserver's outreach efforts and the ISP's subsequent response, remediation work began on the affected infrastructure.

During later verification, I observed that the exposure had been significantly reduced, indicating that corrective actions had been implemented.

Barry later confirmed that, according to Shadowserver's records, the issue had been resolved, and the case was officially closed.

A Memorable Ending

Before closing the conversation, Barry shared a message that has stayed with me ever since:

"Someday you'll find a zero-day, and then the fun begins."

For me, this research was about much more than discovering a misconfiguration.

It was my first experience working alongside an organization dedicated to Internet-wide coordinated vulnerability disclosure.

More importantly, it reinforced a lesson that every security researcher eventually learns:

Finding a vulnerability is only the beginning.

Making sure it reaches the right people and ultimately gets fixed is what truly makes a difference.

This experience shaped how I approach responsible disclosure today. The collaboration with Shadowserver demonstrated that persistence, professionalism, and the right partnerships can turn even the most challenging disclosure scenarios into successful outcomes.

About the Author

i am Ahmed Embaby (0xembaby) is a Cybersecurity Researcher specializing in Web and Network Penetration Testing, Vulnerability Research, and Offensive Security. His research focuses on identifying authorization flaws, business logic vulnerabilities, authentication issues, GraphQL security weaknesses, and other high-impact security vulnerabilities through responsible disclosure.

follow me on my linkedin :

www.linkedin.com/in/ahmed-embaby-077101295