What are the signs that an internet-exposed database is being targeted or compromised?

The clearest warning signs are repeated scanning, very rapid connection attempts, unexpected database access from unfamiliar IP addresses, and evidence of data exfiltration or table changes. In the article, honeypots were scanned every three hours on average and breached in seconds after interaction, which shows how little time defenders may have once exposure is visible.

What the network and access pattern tells you

An internet-exposed database rarely goes from quiet to fully compromised without leaving a trail. The earliest indicators are usually normal internet scanning behaviour turning into repeated connection attempts, logins from unfamiliar geographies or hosting providers, and probe activity that targets default ports, weak protocols, or known admin endpoints. If you see a sudden rise in rejected connections, failed authentication, or strange client fingerprints, treat it as active targeting rather than background noise.

Rapid follow-on attempts after first contact are especially concerning because they suggest the service was not just discovered, it was being tested for weakness. In practice, that means your logs should be able to distinguish passive scanning from interactive enumeration, credential guessing, and authenticated sessions that appear too quickly after exposure.

Repeated scans from the same IP ranges or botnets
Bursts of failed logins, resets, or handshake errors
Access from unfamiliar ASN, country, or cloud-hosted sources
New client user agents, database drivers, or unusual connection timing

Operational signs of compromise in the database itself

Once an attacker moves from probing to access, the signs shift from traffic patterns to data and control-plane anomalies. Unexpected table creation or deletion, schema changes, privilege changes, disabled auditing, and export-like query bursts are all strong indicators that the database is being manipulated or staged for theft. This is where direct evidence matters, because configuration drift alone can be a routine admin change, while concurrent access plus mass reads or writes is much harder to dismiss.

For exposed systems, the presence of unauthorised reads is often more important than a dramatic outage. Exfiltration can be quiet, especially if the attacker only needs a narrow slice of records or wants to validate that the database is worth returning to later.

Table edits, truncation, new indexes, or schema modifications you did not schedule
Large exports, backup-like queries, or repeated full-table reads
New accounts, role grants, or privilege escalation inside the database
Audit log gaps, logging disabled, or retention settings changed unexpectedly

Risk and Threat Considerations

Internet exposure compresses the time between discovery and abuse. In exposed database environments, opportunistic scanning quickly turns into exploitation of weak authentication, misconfiguration, or unnecessary public reachability, and once an attacker has a valid session the priority usually becomes data theft or persistence. NHIMG’s Ultimate Guide to Non-Human Identities notes that 91.6% of secrets remain valid five days after the targeted organisation is notified, which is a useful reminder that exposure often outlives detection by days, not minutes.

Failure mechanism: A database is discovered through public scanning, then probed for weak credentials, permissive network paths, or exposed administrative functions. If authentication or authorisation is weak, the attacker can enumerate data, alter records, or disable logging before defenders see clear business impact.

Impact: The likely outcomes are data exfiltration, silent integrity loss, service disruption, and a longer dwell time because the earliest signs can look like ordinary internet noise. For exposed databases, delayed containment usually expands blast radius because copies, replicas, and downstream consumers may already have inherited the compromised data.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
CIS Controls v8	6 — Access Control Management	Internet-exposed databases need restricted access paths and rapid revocation when suspicious access appears.
	8 — Audit Log Management	The signs discussed depend on logs that show scans, login failures, and data access anomalies.
Recommendation — Restrict database exposure and revoke any unexpected access paths immediately. Enable and protect database audit logging so scan and exfiltration patterns remain visible.
NIST CSF 2.0	DE.CM — Continuous Monitoring	Repeated scanning, unfamiliar access, and export bursts are monitoring signals for exposed databases.
	RS.AN — Analysis	The question is about recognising compromise indicators quickly enough to analyse incident severity.
Recommendation — Monitor database traffic and access patterns for sudden changes in source, volume, and behaviour. Analyze suspicious database activity as a potential compromise and scope affected data immediately.
OWASP Non-Human Identity Top 10	NHI-01 — Secrets and Credential Exposure	Exposed databases are often compromised through leaked credentials, tokens, or misconfigured access paths.
	NHI-02 — Over-Privileged Identities	Unauthorized access becomes far more damaging when database identities can read or change broad datasets.
	NHI-10 — Visibility and Monitoring Gaps	The warning signs depend on visibility into scans, sessions, changes, and exports across database activity.
Recommendation — Find and rotate any credentials that can authenticate to the exposed database. Reduce database account privilege so a compromise cannot expose or alter unnecessary tables. Instrument database access and changes so unusual scans, reads, and writes are detectable.
MITRE ATT&CK	T1190 — Exploit Public-Facing Application	Internet-exposed databases are often targeted through public exposure, weak controls, or known flaws.
	T1005 — Data from Local System	Unexpected table reads and export bursts are consistent with attacker collection activity from the database.
	T1078 — Valid Accounts	Unexpected access from unfamiliar IPs often means valid credentials or sessions were abused.
Recommendation — Hunt public-facing exposure paths and treat any exploit attempt against the database as active targeting. Look for high-volume reads and export-like queries as evidence of collection activity. Investigate unfamiliar authenticated sessions as possible valid-account abuse.

Practitioner Guidance

What to verify: Confirm whether the database is actually intended to be reachable from the internet, then verify whether the exposed listener is protected by strong authentication, source restrictions, and logging that captures both failed and successful access. If you cannot prove those controls from logs and configuration, assume the database is already in an incident-prone state.

Decision rule: If you see repeated scanning plus any sign of successful access, treat it as a containment event, not a tuning issue. Prioritise access review, credential rotation, and query forensics before debating whether the attacker actually got sensitive rows, because exfiltration can be small, staged, and hard to prove after the fact.

Practitioner takeaway: The most reliable signal is the combination of hostile discovery traffic and database-side change, because that pairing shows the system has moved from exposure to active use.