Oracle Default Accounts (Nessus 22075): Find and Lock Them with DBA_USERS_WITH_DEFPWD

Oracle Default Accounts (Nessus plugin 22075) means the scanner found accounts in your Oracle database that still use a well-known default password. To fix it, query DBA_USERS_WITH_DEFPWD, then lock and expire every account you do not need, give the ones you need a strong unique password, and drop unused sample schemas such as SCOTT.

No patch clears this finding. It is an account configuration problem, and it needs to be fixed separately in every container of every database the scanner reached.

What the scanner is actually detecting

Plugin 22075 is a remote check in the Nessus Databases family. Tenable’s synopsis reads: “One or more default accounts have been found in the remote database.” According to the plugin description, the accounts may come from older Oracle versions or from third-party software that uses Oracle.

This check does not run in a default scan. Tenable’s scan settings documentation lists Brute Force > General Settings > Only use credentials provided by the user, which is enabled by default specifically to stop Nessus from testing default accounts, and Brute Force > Oracle Database > Test default accounts (slow), which is disabled by default. If the finding appears, someone chose to test default credentials, and the check needed to reach the listener and find a SID.

Real-world risk, stated honestly

Oracle’s security guidelines say that when you create a database with Database Configuration Assistant (DBCA), most default accounts are automatically locked and expired. Only SYS and SYSTEM are left open, plus SYSMAN and DBSNMP when Enterprise Manager is installed. In practice, open default accounts come from manual installations (where no default users are locked), upgrades that carried accounts forward from older releases, and third-party products.

• SYS, SYSTEM or another administrative account: anyone who can reach the listener has full control of the database. Fix this first.
• Sample or low-privilege account: direct data exposure is limited to what the account owns or has been granted, including anything granted to PUBLIC. An authenticated session still gives an attacker a foothold for privilege escalation bugs on an unpatched database.
• Expired but unlocked accounts: expiring the password alone does not protect the account. Oracle’s DBA_USERS reference states that an EXPIRED user “can log in with the expired password, then change the password”, so anyone who knows the default password can take over the account.

An attacker needs network access to the listener to exploit this, so restricting who can reach port 1521 lowers the risk, though it does not fix the accounts. The same exposure is relevant when hardening the Oracle TNS listener.

How to confirm it on the host

Connect as SYSDBA. In a multitenant database, DBA_USERS_WITH_DEFPWD shows common users when queried from the CDB root and local users when queried from a PDB, so run the query in both places.

sqlplus / as sysdba

SHOW PDBS

-- Run once in CDB$ROOT, then in each PDB:
-- ALTER SESSION SET CONTAINER = ORCLPDB1;
SELECT d.username, d.product, u.account_status,
       u.oracle_maintained, u.common, u.last_login
FROM   dba_users_with_defpwd d
JOIN   dba_users u ON u.username = d.username
ORDER  BY u.account_status, d.username;

Read the ACCOUNT_STATUS column carefully. The view also lists locked accounts: Oracle’s own documentation example shows SCOTT as EXPIRED & LOCKED. The rows that need action are OPEN, EXPIRED, EXPIRED(GRACE) and anything marked (TIMED). A LOCKED(TIMED) status is a temporary lock caused by failed logins, and it clears by itself once PASSWORD_LOCK_TIME has elapsed. On Oracle Database 19c from Release Update 19.32, the view also reports default password combinations for SYS, SYSTEM and ADMIN.

Check what each open account can do:

SELECT granted_role FROM dba_role_privs WHERE grantee = 'SCOTT';
SELECT privilege    FROM dba_sys_privs  WHERE grantee = 'SCOTT';

To reproduce the scanner’s result from another machine, connect with Easy Connect syntax. The -L option stops SQL*Plus from prompting you again if the login fails. Each failure counts toward FAILED_LOGIN_ATTEMPTS (10 in the default profile), so only test account names from the report.

sqlplus -L scott@//db01.example.com:1521/orclpdb1

How to fix it

Step 1: classify each account

Step 2: lock and expire accounts you do not need

Oracle’s guidelines give this exact pattern:

ALTER USER anonymous PASSWORD EXPIRE ACCOUNT LOCK;

-- Common user in a CDB (run in CDB$ROOT): blocks login to every PDB
ALTER USER dbsnmp PASSWORD EXPIRE ACCOUNT LOCK CONTAINER = ALL;

-- Local user inside a PDB
ALTER SESSION SET CONTAINER = ORCLPDB1;
ALTER USER scott PASSWORD EXPIRE ACCOUNT LOCK;

A locked account still appears in DBA_USERS_WITH_DEFPWD because the default password is still set. For accounts where ORACLE_MAINTAINED is N, also replace the password in the same statement (ALTER USER scott IDENTIFIED BY “replace-with-long-random-value” PASSWORD EXPIRE ACCOUNT LOCK;) so the view is empty.

Step 3: set strong passwords on accounts you need

ALTER USER system IDENTIFIED BY "replace-with-long-random-value";
ALTER USER dbsnmp IDENTIFIED BY "replace-with-another-value" ACCOUNT UNLOCK;

Oracle recommends passwords of 12 to 30 bytes and advises against reusing passwords the account had in earlier releases. Give SYS, SYSTEM, SYSMAN and DBSNMP different passwords, and update Enterprise Manager’s monitoring credentials, scripts and any Data Guard standby password files in the same change window.

Step 4: remove unused sample schemas

-- Anything outside SCOTT that depends on it?
SELECT owner, name, type FROM dba_dependencies
WHERE  referenced_owner = 'SCOTT' AND owner <> 'SCOTT';
SELECT owner, synonym_name FROM dba_synonyms
WHERE  table_owner = 'SCOTT' AND owner <> 'SCOTT';

-- Optional safety copy, then drop
-- expdp system@//localhost:1521/orclpdb1 SCHEMAS=scott DIRECTORY=DATA_PUMP_DIR DUMPFILE=scott.dmp LOGFILE=scott_exp.log
DROP USER scott CASCADE;

Oracle also ships drop_sch.sql for the GitHub sample schemas and drop_hr.sql for HR.

Step 5: schema owners nobody logs in as

From Oracle Database 18c onward, you can turn an application schema that only owns objects into a schema only account, which prevents logins entirely: ALTER USER app_owner NO AUTHENTICATION; Do not do this for accounts that applications connect as.

How to verify the fix and rescan

1. Run this query in the root and in every PDB. It should return no rows:

   SELECT d.username, u.account_status
   FROM   dba_users_with_defpwd d
   JOIN   dba_users u ON u.username = d.username
   WHERE  u.account_status NOT IN ('LOCKED', 'EXPIRED & LOCKED', 'EXPIRED(GRACE) & LOCKED');

2. Repeat the remote SQL*Plus test. You should get ORA-28000 (account locked) or ORA-01017 (invalid credentials).
3. Rescan with the same policy and keep default account testing enabled. If that option is off, plugin 22075 does not run, and a clean result proves nothing.

What can break and how to roll back

• Jobs or applications that log in as the account start getting ORA-28000 errors. Check LAST_LOGIN before you lock anything.
• Enterprise Manager monitoring stops working if DBSNMP changes and the stored credentials are not updated.
• Clients still using the old password will lock the account once they reach FAILED_LOGIN_ATTEMPTS.
• Dropping a schema with CASCADE invalidates views, synonyms and procedures in other schemas that reference it, and drops foreign keys that point at its tables.
• Oracle-maintained accounts must not be dropped. The DBA_USERS reference says to change them only through Oracle-supplied scripts.

To roll back, run ALTER USER name ACCOUNT UNLOCK; and set a new strong password, not the default one, or the finding will come back. Restore a dropped schema from the export with impdp using the same SCHEMAS, DIRECTORY and DUMPFILE values.

Common false positive reasons

Because this plugin actively tests credentials, a hit is usually real. Disputes usually come from one of these causes:

• Wrong container or instance: the listener serves several SIDs or PDBs, and you checked a different one from the one the plugin found.
• Timing: the account showed LOCKED(TIMED) when you checked (possibly because of the scan’s own attempts) and has since unlocked itself, or it was fixed after the scan ran.
• Query-based audits: locked accounts that still have default passwords keep showing up in DBA_USERS_WITH_DEFPWD.
• Vendor schemas: the hit is real, but the fix belongs to the vendor. If you cannot change the account yet, record it through a risk acceptance process instead of excluding it from scans.

For broader diagnosis, see common causes of vulnerability scanner false positives.

FAQ

Is PASSWORD EXPIRE alone enough?

No. An expired account still accepts the old password once and lets the user choose a new one. Always combine it with ACCOUNT LOCK or with a new password.

Can I drop OUTLN, DBSNMP or other Oracle accounts?

No. Accounts with ORACLE_MAINTAINED set to Y belong to Oracle components. Lock and expire them instead.

Why does one scan report 22075 and another does not?

Default account testing is off unless a policy enables it, and the plugin also needs to reach the listener and discover a SID.

Do newer releases avoid this?

Mostly. In Oracle Database 19c, most predefined accounts are schema only accounts, and sample schemas are locked and expired at installation. Upgraded databases can still carry old accounts forward.

Tracking this finding across many hosts

Default accounts tend to come back when databases are cloned, upgraded or rebuilt from old scripts, so treat 22075 as a recurring check. SITEY, a self-hosted vulnerability management platform, imports these results when you upload a .nessus export, merges duplicate findings from the same scanner, and can re-test an individual Nessus finding after each database is fixed to confirm it is closed. Its AI can also draft host-specific remediation scripts, which run only after a person approves them.

Sources

• Tenable: Oracle Default Accounts (Nessus plugin 22075)
• Tenable Nessus: Assessment scan settings (Brute Force)
• Oracle Database 19c Reference: DBA_USERS_WITH_DEFPWD
• Oracle Database 19c Security Guide: Finding user accounts that have default passwords
• Oracle Database 19c Security Guide: Guidelines for securing user accounts and privileges