nmap -sV -p 27017 target
nmap -sV -sC --script=banner -p 27017 target
nc -zv target 27017
nmap -sV to identify the exact service and versionsearchsploit mongodb to find known exploitsMongoDB on port 27017 is the default port for MongoDB document database servers. MongoDB became the canonical "NoSQL" database — JSON-like document storage, popular for modern web applications, microservices, real-time analytics. Default port 27017 (configuration database), 27018 and 27019 for sharding configurations.
MongoDB has a notorious history of internet-exposed instances with no authentication. For years, MongoDB shipped with no authentication required by default — install the database, start it, anyone on the network could connect with full administrative access. Combined with default-bind to all interfaces and frequent direct internet exposure, this produced the Mongo Lock ransomware wave in 2017 and recurring waves since. Hundreds of thousands of MongoDB instances were wiped or held for ransom. Modern MongoDB defaults to localhost-binding and requires authentication setup, but legacy deployments and misconfigured instances continue to be discovered and abused.
For defenders: require authentication always (--auth flag or security.authorization: enabled in config), bind only to internal interfaces (net.bindIp in config, never 0.0.0.0 unless explicitly intended), firewall block port 27017 from public internet, use TLS for connections, create dedicated application users with role-based access control (RBAC), never use admin database users for application connections, and monitor for unusual access patterns.
Standard external recon: nmap -p 27017,27018,27019 target_range, masscan for wide scans, Shodan queries for "MongoDB" headers. Internet-exposed MongoDB is always critical-priority finding. Test for authentication: mongosh "mongodb://target:27017/" — if it connects without credentials, the instance is unauthenticated.
When unauthenticated MongoDB is found, escalation is immediate: enumerate all databases (show dbs), enumerate collections within each (show collections), dump sensitive data (db.users.find()). MongoDB unauthenticated typically means full administrative access — read everything, modify everything, drop databases, exfiltrate data.
MongoDB ransomware investigation: check current databases for ransom note patterns (often replaces all data with single document containing payment instructions), check binary logs and audit logs for connection patterns, check modification timestamps on data files. Recovery typically requires restoring from backup; payment to ransomware actors does not reliably recover data.
Code review: check application connection strings for credentials in plain text vs secure config management, check for usage of admin database users vs dedicated app users, verify TLS enabled on connection. Configuration review: verify mongod.conf has authorization enabled, bindIp restricted, TLS configured.
Most compliance frameworks treat unauthenticated database access as a critical control failure. SOC 2, ISO 27001, PCI DSS, HIPAA all require authenticated access to data stores, encryption in transit and at rest, audit logging. MongoDB Atlas (managed cloud) handles much of this automatically; self-hosted deployments require explicit configuration.
Older MongoDB versions defaulted to no authentication. Modern versions require explicit auth setup. Verify with mongosh connecting without credentials — if it works, authorization is not enabled. Set security.authorization: enabled in mongod.conf and create initial admin user.
Old default was bind to all interfaces; modern default is localhost-only. Verify with netstat -an | grep 27017 or check net.bindIp in config. Should be 127.0.0.1 for local-only or specific private IP for app-server access — never 0.0.0.0 unless explicitly intended.
Default MongoDB connections are cleartext. Configure TLS via net.tls.mode: requireTLS in mongod.conf with cert/key paths. Application connection strings updated to specify TLS. Encrypts both authentication and data in transit.
Applications connecting as admin users have full database control — escalation impact of credential compromise or NoSQL injection is total. Create per-application users with specific RBAC roles (read on specific databases, readWrite on specific collections). MongoDB has fine-grained RBAC; use it.
MongoDB Enterprise has audit logging; community edition has limited options. Without audit logs, compromise investigation is severely constrained. For sensitive deployments, MongoDB Enterprise or Atlas (which includes auditing) is worth the cost. Self-hosted community edition: at minimum log connection attempts and authentication failures.
Network-based defences depend on network actually being inaccessible to attackers. Insider threats, lateral movement after initial compromise, misconfigured firewalls, accidental exposure during cloud migrations all bypass network defences. Authentication, encryption, and RBAC are independent of network controls and should be in place regardless.
security: authorization: enabled. Restart MongoDB. Connect with no auth one last time and create initial admin user: use admin; db.createUser({user: "admin", pwd: "strong_password", roles: ["root"]}). After this, all connections require authentication.nmap -p 27017 your.public.ip. Internal: check bind-address in mongod.conf (net.bindIp) — should be 127.0.0.1 or specific private IP, not 0.0.0.0. Plus firewall rules confirming port 27017 blocked at perimeter.use app_db; db.createUser({user: "app_user", pwd: "strong_password", roles: [{role: "readWrite", db: "app_db"}]}). The user can read and write only in app_db, no access to other databases, no admin privileges. Application connection string uses this user instead of admin root.db.users.find({user: req.body.user, pass: req.body.pass}) can be exploited if req.body.pass is an object like {$ne: ""}. Mitigations are at application layer (validate input types, use query builders that handle escaping). Database-side: minimum-privilege application users limit blast radius.net.tls.mode: requireTLS with paths to certificate and key files. Restart MongoDB. Application connection strings updated to enable TLS verification. Encrypts both authentication credentials and data in transit. Standard practice for any production MongoDB.