Secrets in Office Files: Finding Credentials in Spreadsheets, Macros and Connection Files

Database passwords, API keys and service account logins sit inside workbooks, macros and data connection files that no secrets scanner was ever pointed at. Business users build reports that pull from SQL Server, push to SaaS APIs or refresh from a data warehouse, and the easiest way to make the refresh work for everyone is to save the password with the connection or paste a token into a VBA module. Those files are then emailed, copied to shared drives and synced to cloud storage, so the credential travels with them and outlives the person who created it. This guide covers where credentials hide in Office files, how to find them at scale, how to triage and remove them, and how to stop new ones appearing. It is written for security, identity and data protection teams who own non-human identity (NHI) hygiene, and goes deeper on credentials than the broader End-User Computing and Spreadsheet Risk Guide, which covers model and integrity risk.

Key takeaways

• Office files are an unscanned secrets store. Saved connection passwords, VBA string constants and exported connection files hold the same credentials your code scanners look for in Git, but in file shares and mailboxes.
• Microsoft says the saved password is not encrypted. Excel's own Connection Properties documentation warns that the "Save password" option stores logon information that may be plain text.
• Every credential found is an NHI to own. A shared SQL login or API token in a workbook is a machine identity with no owner record, no rotation and no leaver process until you create one.
• Revoke and rotate before you clean files. Copies already exist in backups, mail and sync clients, so deleting the string from one file does not remove the exposure.
• Replace, then prevent. Move refreshes to integrated authentication, a gateway or a managed service account, then use DLP credential detection and macro policy to stop the pattern returning.

Where credentials hide in Office files

Modern Office documents (.xlsx, .xlsm, .docx, .pptm) are ZIP packages of XML parts, so a credential written by Excel or by a user ends up as readable text inside the package. Older binary formats and companion files carry the same data in other forms. MITRE ATT&CK describes the attacker side of this as T1552.001 Credentials In Files: searching local systems and file shares for files that store credentials, including files users create for their own passwords and configuration files that hold passwords for a system or service.

Two of these deserve particular attention because Office creates them on the user's behalf. Microsoft's Connection Properties documentation says the "Save password" check box saves the user name and password in the connection file, that "the saved password is not encrypted", and that the information may be stored as plain text that a malicious user could use against the data source. The VBA object model exposes the same setting as the SavePassword property, which, when True, keeps the password in the ODBC connection string used by QueryTables and PivotTables.

Why these are non-human identity problems

The credential in a workbook is rarely the analyst's own password. It is usually a shared SQL login, a reporting service account, an integration user in a SaaS tenant or an API key issued to a team. That makes it a non-human identity with the usual NHI gaps: no named owner, no expiry, broad rights granted to make the report work, and no link to joiner, mover and leaver events. See the Service Account Security Guide.

• Blast radius: reporting logins are often granted read access to whole databases, or db_owner, because that was the quickest way to stop errors.
• Copy count: a single workbook can exist in dozens of mailboxes, OneDrive folders, backups and laptops, each a copy of the secret.
• No rotation: rotating the password breaks every report that holds it, so owners avoid rotation and the credential becomes permanent.
• Invisible to inventory: NHI discovery tools that read identity providers, cloud IAM and CI/CD do not see a connection string inside a file. See the NHI Discovery Across Cloud, SaaS, CI/CD and On-Premises Environments.

NIST SP 800-53 Rev. 5 control IA-5(7) No Embedded Unencrypted Static Authenticators applies directly: its guidance extends "static storage" beyond applications to access scripts and function keys, and notes that an authenticator used in the form it is stored counts as unencrypted. A macro constant or a saved connection password meets that definition.

Finding credentials at scale

Discovery needs two passes: a content inspection pass that reads inside files, and a structural pass that looks for the file types and settings that usually carry credentials, whether or not a pattern matches.

Content inspection with DLP classifiers

Microsoft Purview provides a bundled sensitive information type called All Credentials, which groups 41 credential detectors. They include Azure SQL Connection String, Azure Storage Account Access Key, Microsoft Entra Client Secret, GitHub Personal Access Token, Google API key, Slack Access Token, Amazon S3 Client Secret Access Key, Http Authorization Header, X.509 Certificate Private Key, User Login Credentials and General Password. Purview documents some limits that matter for this use: General Password detects password keywords in English only, and credential types in an endpoint DLP policy need Advanced classification scanning and protection turned on.

Purview DLP can inspect SharePoint and OneDrive (existing and new items), Exchange Online (new messages), Teams, Windows and macOS endpoints, and on-premises file shares and SharePoint Server through the Information Protection scanner. Other DLP and data security platforms offer comparable credential classifiers; the approach is the same whichever you use. See the Microsoft Purview Information Protection Guide and the Data Loss Prevention (DLP) Guide.

Structural search

• File types: list every .odc, .udl, .iqy, .dqy, .xlsm, .xlam, .docm, .accdb and .mdb on file shares and in SharePoint libraries, with owner and last-modified date. These are the population to inspect even when no classifier fires.
• Package parts: for ZIP-based formats, the workbook's connections part and the VBA project part can be extracted and searched for Password=, PWD=, User ID=, UID=, Authorization, Bearer, api_key and key-like strings.
• Repository scanners: many secret scanners used for Git can also scan a directory tree. Pointing one at an export of macro source and extracted XML parts catches token formats DLP classifiers do not know. OWASP recommends using more than one detection tool and correlating results to find gaps.
• Database side: list service logins connecting from Excel, Access or ODBC clients on user workstations; one login used from many desktops points to a shared credential in a file.

Choosing the discovery approach

Triage and response

Treat every confirmed credential as exposed. OWASP's Secrets Management Cheat Sheet sets the order: revoke the secret, rotate it, delete it from exposed locations, then review who had access and when it was used. In Office files the order matters more than usual, because deleting one copy leaves the others.

1. Classify the finding: confirm it is a live credential, identify the system it opens and the identity it belongs to (shared SQL login, service account, API key, personal password).
2. Find the owner: the file author, the data source owner and the business owner of the report. Record the credential as an NHI in your inventory with all three.
3. Check use: review authentication logs on the target for the credential: source hosts, times and anything outside the expected pattern. Unexpected sources move the finding into incident response.
4. Rotate or revoke: for shared logins, prepare the replacement (step below) first so reports keep working, then rotate. For API keys, issue a new scoped key and revoke the old one.
5. Clean the file: clear the saved password (untick "Save password" or set SavePassword to False), remove the constant from VBA, delete the parameter sheet, and replace exported .odc files.
6. Chase copies and close: use classifier hits to find copies in mail, OneDrive and shares, then record the new authentication method, owner and review date.

Severity rises with privilege and reach: an administrative SQL login or a cloud storage key in a file shared externally is a priority-one finding; a read-only login to a retired test database in a personal folder is low. See the Developer Secret Scanning Triage for scoring approaches that transfer well.

Replacing embedded credentials

Rotation alone fails here because the next refresh needs a password, and the user will save the new one. Remove the need for a stored secret.

Where a non-human credential must remain, give it a named owner, least privilege on the target (read-only, specific views), an expiry or rotation schedule and storage in a secrets manager. See the Secrets Management Guide and the Database Credential and Access Security Guide.

Preventing new credentials in files

• DLP policy tips and blocks: apply a credential classifier policy to SharePoint, OneDrive, Exchange and endpoints, starting in test or audit mode, then policy tips, then blocking external sharing.
• Macro policy: enable "Block macros from running in Office files from the Internet" for each Office app (for Excel under User Configuration\Policies\Administrative Templates\Microsoft Excel 2016\Excel Options\Security\Trust Center). Microsoft notes that files in Trusted Locations skip the Mark of the Web check, that network Trusted Locations are not recommended, and that files synced by the OneDrive client or opened with "Open in Desktop App" do not carry Mark of the Web, so control who can write to those locations.
• Signed macros only for approved tools: fewer unsigned macros means fewer places for hard-coded keys to hide, and a review step at signing time.
• Published connection files: provide approved .odc or dataset connections that use integrated authentication, so users have no reason to build their own.
• Leaver and mover events: include files and connections the person owned in offboarding, and reassign or retire them. See the Employee Offboarding Security Guide.

Implementation plan

1. Weeks 1 to 2, scope: agree locations (shares, SharePoint, OneDrive, mail, endpoints), the classifier set and the triage owner. Run database login analysis to list shared logins used from desktops.
2. Weeks 2 to 4, discovery in audit mode: run credential classifiers and the structural search; no blocking. Measure volume and false positives on a sample.
3. Weeks 4 to 8, high-privilege remediation: rotate administrative and externally shared credentials first, with replacements in place, using a pilot group of report owners to test refresh.
4. Months 2 to 4, bulk remediation: work through remaining findings by data source, so one migration to integrated authentication fixes many files at once.
5. Months 3 to 6, prevention: move DLP from audit to policy tips, then to blocking external sharing; apply macro policy through pilot rings.
6. Rollback: keep the previous credential disabled rather than deleted for a short agreed window so a broken critical report can be restored while it is fixed, and revert DLP rules to audit mode if blocking disrupts business processes.

Small organisations can run the same plan without DLP licences: a structural search with an open-source secret scanner over shared drives, a list of shared database logins, and a rule that new reports use integrated authentication.

Detection and measurement

Log and alert on authentication to data sources by credentials found in files (after rotation, any attempt with the old secret is a signal), new DLP credential matches in shared or externally shared files, and service logins used from unusual desktops.

• Open credential findings by severity and age, with a target time to rotate for priority-one items.
• Shared logins used from end-user devices, trending down as reports move to integrated authentication.
• Files with saved connection passwords found per month (new versus remediated).
• Percentage of credential findings with a named owner recorded in the NHI inventory.
• DLP credential matches on external sharing, and the share of those blocked or overridden with justification.

Framework mapping

Common failure patterns

• Cleaning the file, not the credential: the password is removed from the workbook but never rotated, while copies remain in mail and backups.
• Rotating without a replacement: reports break, owners save the new password in the same way within days, and the finding reopens.
• Scanning only code repositories: secret scanning covers Git while departmental shares full of .xlsm and .odc files are never inspected. See the Git Secret Scanning Guide for the repository side.
• Trusting a single classifier: English-only password keywords and unknown token formats leave gaps that a structural search would catch.
• Broad Trusted Locations: a network share set as a Trusted Location lets any macro there run, including ones holding credentials, which Microsoft's guidance advises against.
• No owner after discovery: findings sit in a DLP console with nobody accountable for the identity behind them.

Practitioner checklist

• Run a credential classifier across SharePoint, OneDrive, mail and on-premises shares in audit mode.
• List all .odc, .udl, .iqy, .dqy, macro-enabled and Access files with owners.
• Search connection and VBA parts for password, token and connection string patterns.
• Identify shared database logins used from end-user devices.
• Record each confirmed credential as an NHI with technical and business owners.
• Rotate or revoke priority-one credentials after putting integrated authentication or a vault-backed service in place.
• Clear saved passwords and remove hard-coded secrets from macros and parameter sheets.
• Enable the internet macro block policy and review Trusted Locations.
• Move DLP credential policies from audit to tips to blocking external sharing.
• Add owned files and connections to leaver and mover processing.

Standards and references

• NIST: SP 800-53 Rev. 5
• MITRE ATT&CK: Unsecured Credentials: Credentials In Files
• OWASP: Secrets Management Cheat Sheet
• Microsoft Support: Connection properties
• Microsoft Learn: ODBCConnection.SavePassword property
• Microsoft Learn: All credentials sensitive information type
• Microsoft Learn: Macros from the internet are blocked by default in Office
• Microsoft Learn: Authentication with a data source (Power Query)

Related NHI Mgmt Group resources: End-User Computing and Spreadsheet Risk Guide · Secrets Management Guide · Service Account Security Guide · NHI Discovery Across Cloud, SaaS, CI/CD and On-Premises Environments · Data Loss Prevention (DLP) Guide