Scrub secrets from network configs before you share them

Sooner or later, every network engineer is asked to send a config to someone. A vendor support case needs the running config. A colleague wants to see how you built that VPN. A forum post would be so much easier to answer with the real file attached. You copy it, you paste it, and somewhere in those few hundred lines sit an SNMP community, a pre-shared key and an admin hash you forgot were there.

This post is a checklist for that moment. It covers where secrets hide in config backups, scripts and screenshots, how to clean a file without wrecking it, which tools catch what your eyes miss, and what to do, in which order, when something has already escaped. Each section ends with boxes you can tick.

Why this deserves a checklist

Attackers know exactly where to look. MITRE ATT&CK lists Credentials In Files as sub-technique T1552.001 under the Credential Access tactic: adversaries search local file systems and file shares for files that store credentials insecurely, including configuration files with embedded passwords, source code with hard-coded passwords, and backups. Its listed mitigations are plain and useful: audit for password-bearing files, prohibit storing passwords in files, restrict file share permissions, and train administrators and developers about plaintext passwords in config files.

The developer side of the same problem has its own entry. CWE-798, Use of Hard-coded Credentials, describes products that carry a built-in password or key, either for people logging in (inbound) or for the product connecting to another system (outbound). For the inbound case, CWE notes that the hard-coded password is the same on every installation, so once it is discovered or published, anyone who knows it can get in. The weakness appears in every CWE Top 25 list from 2019 through 2024.

Network gear is not exempt. A good example is Fortinet's advisory FG-IR-19-007 (CVE-2019-6693): FortiOS used a hard-coded key to encrypt the "ENC" credential values in CLI configurations and backup files, so anyone with the key and a copy of the file could recover them. NVD's entry lists the exposed data as user passwords (except the administrator's), private key passphrases and the HA password, maps it to CWE-798, and shows that CISA added it to the Known Exploited Vulnerabilities catalog on 25 June 2025. The fix was a setting, private-data-encryption, which replaces the built-in key with one you choose, and Fortinet's advice until then was to password-protect backups and avoid sharing configs publicly.

The lesson I take from it: a value that looks encrypted in a config is not automatically safe to share. Always ask what key protects it and who else has that key.

Where secrets hide in network configs

When I review a file before it leaves my hands, I look for these families of values. The table is generic; your vendors will spell the keywords differently.

A few of these need a closer look.

Cisco type 7 is not encryption. Cisco's own paper, Protecting Secrets on Cisco Network Devices, explains that the long-standing password-encryption setting produces type 7 values using the Vigenère cipher with a static key embedded in the operating system, a key that was publicly discovered decades ago, so type 7 should be treated like plain text. The same paper sorts device secrets into non-reversible ones (login passwords, which the device only verifies) and reversible ones (TACACS+/RADIUS keys, routing authentication keys), which the device must decrypt to use. It also lists how attackers actually get configs: known credentials, stolen flash cards, unauthenticated TFTP or HTTP servers holding config files, and files harvested from an administrator's own computer.

SNMP communities are passwords. RFC 3410 (Section 8.2) says SNMPv1 and SNMPv2c support only trivial authentication based on plain-text community strings, which makes them fundamentally insecure. If the community is in the file, whoever reads the file gets whatever access that community was given.

Encrypted blobs depend on their key. Palo Alto Networks' firewalls encrypt all passwords and private keys with a master key, and the master key documentation recommends configuring your own key instead of keeping the default. I still remove those blobs before sharing: the person receiving the file does not need them, and I'd rather not depend on how the key was managed.

Hashes are still secrets. Cisco's paper calls types 8, 9 and 10 secure: strong hashing with many iterations makes cracking very difficult, which is far better than type 7. The same paper also points out that a hashed account line is portable: configure it on another device and it creates the same user with the same password. Add the general risk that a weak password behind a strong hash can still be guessed offline, and there is rarely a good reason to hand hashes out.

Checklist:

• Search for every keyword family in the table, for each vendor in the file
• Treat type 7 and any "obfuscated" value as plain text
• Treat hashes, encrypted blobs and certificates as sensitive too
• Look beyond the main config: scripts, Ansible or Terraform variables, .env files, exported spreadsheets, and screenshots of CLI sessions

Sanitising a config before sharing

                replace the value, keep the line                
                                                                
  ┌─ backup.cfg ───────────────────────────────┐                
  │ hostname <HOST-1>                          │                
  │ interface ethernet1/1                      │  raw value     
  │  ip address <IP-1>/24                      │    found       
  │ !                                          │  placeholder   
  │ username admin secret 9 <REDACTED>         │                
  │ snmp-server community <REDACTED> ro        ┃                
 ▶│ !                                          ┃◀ scanner       
  │ crypto ikev2 keyring PEERS                 ┃                
  │  pre-shared-key Tr0ub4dor&3                ┃                
  │ !                                          ┃  keywords      
  │ tacacs-server key 7 0822455D0A16           │  stay put      
  │ api-key LUFRPT1xYz9q==                     │                
  └────────────────────────────────────────────┘                
                                                                
  $ sanitize backup.cfg > backup-share.cfg                      

The person you're sending the file to usually needs its shape: which features are on, how the policy is ordered, which peer uses which proposal. They almost never need the values. So the rule I follow is replace, don't delete.

Deleting a line hides that a feature exists at all, and the reviewer may chase a problem that isn't there. Replacing the value keeps the evidence intact:

snmp-server community <REDACTED> ro
crypto ikev2 keyring PEERS
 pre-shared-key <REDACTED>
logging host <IP-2>

A few habits make this work better:

1. Use consistent placeholders. If the same peer address appears in five places, give it the same tag everywhere (<PEER-1>). Then the reader can still follow the logic: "the tunnel to PEER-1 uses proposal B."
2. Keep the mapping offline. If you need to translate the support engineer's answer back to real values, keep the placeholder-to-value table on your own machine, never in the shared file or the ticket.
3. Work on a copy. Sanitise backup.cfg into backup-share.cfg; never edit the only backup you have.
4. Make the tool quiet. A sanitising script should report where it found something (file, line, kind), not print the secret itself. Otherwise the terminal history and the log become the next leak. gitleaks follows the same idea with its --redact flag, which hides secrets in its own output (gitleaks README).
5. Diff before you send. Compare the original and the cleaned copy side by side. Every changed line should be one you meant to change, and every secret should be on a changed line.
6. Check screenshots twice. Blur or crop before you paste. A screenshot can't be searched by a tool the way text can, so this check is up to you.

Checklist:

• Cleaned a copy, not the original
• Replaced values with consistent placeholders; kept every keyword and line
• Mapping table kept offline
• Diffed original vs cleaned copy
• Screenshots cropped or blurred

Scanning repos and folders

Human review misses things, especially in long files and old commits. Two kinds of tools help.

GitHub secret scanning. GitHub's secret scanning looks for credentials across the entire Git history on all branches, plus issues, pull requests, discussions, wikis and secret gists. It runs automatically at no cost on public repositories; organisation-owned private repositories need GitHub Secret Protection. For many partner token types, GitHub notifies the issuing provider so it can act, for example by revoking the token. GitHub's advice when an alert fires is to rotate the credential straight away.

Push protection. Push protection blocks a push that contains a supported secret before it lands. The user-level version is on by default on GitHub.com and covers pushes to public repositories; repository-level push protection is off by default and needs Secret Protection. For repository-level push protection, anyone with write access can bypass a block by default, but they must choose a reason, the bypass is added to the audit log, and owners, security managers and repository administrators who watch the repository get an email about it.

gitleaks, locally and in CI. gitleaks is an MIT-licensed scanner for git repos, directories and stdin. The commands I reach for:

gitleaks git -v path_to_repo           # scan the history of a repo
gitleaks dir -v path_to_config_folder  # scan files that aren't in git, e.g. a backups folder
gitleaks git --redact -v .             # same, without printing the secrets

It can run as a pre-commit hook, so a secret is caught before it is ever committed, and it accepts a .gitleaks.toml for custom rules, which is where you would add patterns for your own vendors' keywords. One note from the README: the maintainer now describes gitleaks as feature complete, with future releases limited to security patches.

Neither tool understands every network config dialect out of the box, so treat a clean scan as "nothing obvious", not "nothing at all". The OWASP Secrets Management Cheat Sheet recommends running detection early (in the IDE or with pre-commit hooks) and using more than one tool, de-duplicating the results.

Checklist:

• Secret scanning and push protection enabled where you can
• gitleaks (or similar) as a pre-commit hook and in CI
• Custom rules for your vendors' keywords
• Folders of backups scanned too, not only repos

Storing secrets properly

The best way to avoid cleaning secrets out of files is not to put them there. The OWASP cheat sheet's main points, in short:

• Centralise secrets in a secrets manager and document what each one is for and where it is used.
• Least privilege: not every engineer needs to read every secret; grant access per secret where the platform allows it.
• Automate rotation, and prefer short-lived, dynamic credentials where possible.
• Keep secrets out of code, config files and container images; have applications fetch them at runtime. OWASP also cautions that environment variables can leak through logs and dumps.
• Never log secrets.

For network devices, that translates into a few concrete moves: use the strongest stored types your platform supports, set your own device keys (a Cisco type 6 config key, a Palo Alto master key, FortiOS private-data-encryption), and keep those keys stored separately from the configs they protect, as Cisco's paper advises for the type 6 key.

If a secret leaked: rotate first, then clean

              rotate first, then clean the history              
                                                                
┌─ git history ──────┐   ┌── VAULT ─────┐                       
│ a1f3 add config    │   │            ◇ │                       
│ c7e9 fix vpn       │   │              │     ┌─ service ──────┐
│ 9b02 key=Kx7qP2v9  │   │ ● Kx7qP2v9   │     │                │
│ e44d docs          │   │              │•─•──│ uses Kx7qP2v9  │
│ ...                │   │              │     │                │
└────────────────────┘   │              │     └────────────────┘
                         │              │                       
                         └──────────────┘                       
                                                                
                      1 rotate → 2 revoke → 3 clean history     
                                                                
ops>                                                            
                                                                

It is tempting to rush to delete the commit or the forum post. Stop and change the order. Both GitHub and OWASP put revocation first:

1. Rotate and revoke. GitHub's guide to removing sensitive data says the first step is to revoke or rotate the secret, and that once it can no longer be used, that may solve the problem without rewriting history. OWASP's incident steps are revoke, rotate, remove, then log.
2. Check whether it was used. OWASP's logging step is about knowing who had access and when the secret was used. Look at the authentication logs for that account or key.
3. Then clean. If the value still needs to go (for example, it reveals a pattern you reuse), GitHub's guide uses git-filter-repo, either to drop a file from all history or to replace strings with --replace-text. It is honest about the costs: commit hashes change, old clones and forks still hold the data, collaborators who pull and push from an old clone can bring it back, and cached views may need GitHub Support.

That list of side effects is the best argument for doing step 1 first. GitHub's own secret scanning page makes the same point: rewriting history is slow and often unnecessary once the credential has been revoked.

The one-page pre-share checklist

Copy this into your notes, ticket template or team wiki.

Before sharing a config, script or screenshot

• Working on a copy, named so nobody mistakes it for the real backup
• Searched for: passwords and hashes, reversible keys (TACACS+, RADIUS, routing, IKE PSK), SNMP communities and v3 keys, API keys and tokens, private keys and certificates
• Type 7 and other "obfuscated" values treated as plain text
• Encrypted blobs and hashes removed too
• Hostnames, public IPs, usernames and organisation names replaced with consistent placeholders
• Placeholder mapping kept offline
• Scanner run over the cleaned copy (gitleaks dir, with --redact)
• Original and cleaned copy diffed
• Screenshots cropped or blurred
• Sent through an approved channel, to the person who needs it

If something leaked

• Rotated and revoked first
• Logs checked for use of the old secret
• Then history, tickets and posts cleaned
• Root cause noted (missing hook? missing rule?) and fixed

None of this is glamorous, and that's fine. A few minutes of checking before you hit send costs much less than rotating every key in a firewall cluster afterwards.

Sources

• MITRE ATT&CK, T1552.001 Unsecured Credentials: Credentials In Files
• MITRE CWE-798, Use of Hard-coded Credentials
• Fortinet PSIRT, FG-IR-19-007: Hardcoded symmetric key in FortiOS configuration backups
• NVD, CVE-2019-6693
• Cisco, Protecting Secrets on Cisco Network Devices (PDF)
• RFC 3410, Introduction and Applicability Statements for Internet-Standard Management Framework
• Palo Alto Networks, Device > Master Key and Diagnostics
• OWASP Secrets Management Cheat Sheet
• GitHub Docs, About secret scanning
• GitHub Docs, About push protection
• GitHub Docs, Removing sensitive data from a repository
• gitleaks on GitHub