Reducing an Organization's Attack Surface

Learning Objectives

• After this, students can plan and run an authorized OSINT self-assessment of an organization.
• After this, students can explain external attack surface management (EASM) and why asset inventory matters.
• After this, students can find and remove sensitive metadata from documents before publishing.
• After this, students can set up secret scanning and respond correctly when a secret leaks.
• After this, students can identify dangling DNS records and explain how subdomain takeover works.
• After this, students can recommend policies for job postings, employee social media, and executive protection.

Do OSINT on Yourself First

Every technique in the intro lesson is something an attacker can run against your organization for free and without being noticed. Defenders have one big advantage: they can run the same recon with full authorization and inside knowledge of what should be exposed.

An organization’s external attack surface is everything about it that’s reachable or knowable from the outside:
- Domains, subdomains, IP addresses, and internet-facing services
- Cloud storage, SaaS tenants, and code repositories
- Published documents and their metadata
- Employees, their roles, and their public profiles
- Vendors, partners, and technologies it uses

The goal of defensive OSINT is to find exposure before attackers do, fix what shouldn’t be public, and accept (with eyes open) what has to stay public.

Running an OSINT Self-Assessment

1. Get authorization and set scope

Even when it’s your own organization, get written sign-off from leadership and define scope, just like a pentest.
- Which domains, brands, and business units are included?
- How will you handle employees’ personal accounts? Most organizations limit the assessment to work-related exposure and report employee findings in aggregate (for example, “40 employees list the internal VPN product in their LinkedIn skills”) rather than naming individuals.
- Where will findings be stored, and who can see them?

2. Follow the OSINT Cycle

Define questions (“What would an attacker need to phish our finance team?”), collect, process, analyze, and report, as covered in Module 3.

3. Work through a checklist

4. Report with owners

Every finding needs a risk rating, a recommended fix, and an owner (the team that can actually fix it). Findings without owners don’t get fixed.

External Attack Surface Management (EASM)

A one-time assessment goes stale fast. External attack surface management is the practice of continuously discovering and monitoring internet-facing assets.

Why it matters:
- Shadow IT: teams spin up cloud services and SaaS tools without telling security.
- Forgotten assets: old test servers, expired marketing campaigns, and abandoned subdomains keep running (or keep pointing somewhere).
- Mergers and acquisitions: acquired companies bring their own unknown attack surface.
- Changing infrastructure: cloud IP addresses change hands constantly.

Options range from open-source tooling (subdomain enumeration, CT log monitoring, scheduled scans of your own assets) to commercial platforms. Many threat intelligence vendors, including Flare, bundle attack surface management with dark web monitoring.

The foundation of EASM is an asset inventory: you can’t protect what you don’t know you own.

Scrubbing Document Metadata

Documents published on a website often carry hidden information:
- Author and “last modified by” names, which often match internal usernames
- Internal file paths (for example, C:\Users\jsmith\Projects\... or \\fileserver01\finance\)
- Software names and versions, which tell attackers what to target
- Printer and server names
- Tracked changes, comments, and hidden sheets or slides
- GPS coordinates in embedded images

Audit what’s already published

# Download the organization's public PDFs (authorized assessment), then:
exiftool -a -G1 report.pdf

# Pull just the interesting fields from a whole folder
exiftool -r -Author -Creator -Producer -LastModifiedBy ./downloaded-docs/

Clean before publishing

• Microsoft Office: File → Info → Check for Issues → Inspect Document removes comments, tracked changes, document properties, hidden content, and more.
• Adobe Acrobat Pro: includes tools to remove hidden information and sanitize a document before publishing (menu names vary by version; verify before class).
• ExifTool: exiftool -all= image.jpg strips metadata from images. For PDFs, ExifTool’s edits may be reversible because the original metadata can remain in the file; rewrite the PDF with a tool like qpdf afterward, or use a dedicated sanitizer (verify before class).
• mat2 (Metadata Anonymisation Toolkit 2): a command-line tool that removes metadata from many file types.

Redaction done wrong

Drawing a black box over text in a PDF does not remove the text underneath. Anyone can copy and paste it or remove the box. Use real redaction tools that delete the content, then verify by searching the final file for the redacted words.

Make it a process

Add a “metadata check” step to the publishing workflow for anything going on the public website, in press kits, or to customers.

Job Posting Hygiene

Job postings are one of the richest OSINT sources about a company’s internal technology. A posting that asks for “5+ years administering [specific firewall model] and [specific EDR product] version X” tells an attacker exactly what to research.

Guidelines to work out between HR, recruiting, and security:
- Describe categories instead of exact products where possible: “experience with enterprise EDR platforms” instead of naming the product and version.
- Use “such as” language when a product name really helps recruiting: “experience with a major SIEM (such as Splunk or similar).”
- Leave out internal details: hostnames, network layouts, org chart specifics, and project code names.
- Watch for staffing signals: “our sole security engineer” or “building our security program from scratch” tells attackers where the gaps are.
- Accept the trade-off: candidates need enough detail to know if they’re qualified. The goal is balance, not secrecy.

Secret Scanning

Why secrets leak

Developers accidentally commit API keys, passwords, and tokens in:
- Source code and config files (.env, config.yaml)
- Jupyter notebooks and scripts
- CI/CD logs and pipeline files
- Git history: a secret removed in the latest commit is still in older commits

Automated bots scan public repositories constantly, so a leaked key can be found and abused very quickly.

GitHub secret scanning and push protection

• Secret scanning detects known secret formats (cloud keys, tokens, etc.) in repositories.
• Push protection blocks a push that contains a detected secret before it reaches the repository. It works for command-line pushes, commits in the web UI, file uploads, and API requests.
• Public repositories: push protection for users is on by default at no cost. When you try to push a secret to a public repo, GitHub blocks it and explains why. Users can bypass by giving a reason (such as “used in tests” or “false positive”), which creates an alert and notifies owners.
• Private repositories: repository-level push protection requires GitHub Secret Protection (part of GitHub’s paid security offerings) to be enabled by an admin.

Gitleaks

Open-source scanner for git repos and files. As of v8.19.0, the older detect and protect commands are deprecated in favor of git and dir:

# Scan a local repository's full history
gitleaks git -v path/to/repo

# Scan a directory or file (not git history)
gitleaks dir -v path/to/directory

TruffleHog

Open-source scanner that can also verify whether a found secret is still active by testing it against the provider’s API. The --results flag replaces the deprecated --only-verified flag.

# Scan a remote repository you own, showing only verified (live) secrets
trufflehog git https://github.com/companyx/example-repo --results=verified

# Scan a local repository
trufflehog git file://path/to/repo --results=verified,unknown

# Scan every repository in your organization
trufflehog github --org=companyx --results=verified

# Scan files on disk
trufflehog filesystem path/to/dir

Because verification sends the discovered credential to the provider’s API, only run TruffleHog against repositories you own or are authorized to test (see Module 2).

When a secret leaks: rotate first

1. Revoke or rotate the secret immediately. Deleting the commit is not enough. The secret is in git history, forks, clones, caches, and possibly already in an attacker’s hands.
2. Check logs for any use of the credential since it was exposed.
3. Clean up the history if needed, knowing that copies may already exist.
4. Find the root cause (missing .gitignore, no pre-commit hook, secrets in code instead of a secrets manager).

Don’t forget other places

• Employees’ personal repositories that contain work code
• Public API collections (such as Postman workspaces), container images, and package registries
• Paste sites and public project boards

DNS Hygiene and Subdomain Takeover

How subdomain takeover works

1. promo.companyx.com has a CNAME record pointing to a third-party service (for example, a hosted page on a cloud platform).
2. The marketing campaign ends and someone deletes the hosted page, but nobody deletes the DNS record.
3. The DNS record is now dangling: it points to a resource that no longer exists.
4. An attacker creates a new resource with the same name on that service and claims promo.companyx.com.
5. The attacker now controls content on a legitimate company subdomain: perfect for phishing, and in some cases for abusing cookies scoped to the parent domain.

The community project “Can I take over XYZ?” (EdOverflow on GitHub) tracks which services are vulnerable, not vulnerable, or edge cases, along with fingerprints to recognize them.

How to find dangling records (your own domains)

# See where a subdomain points
dig CNAME promo.companyx.com +short

# If it points to a third-party service, confirm the resource still exists
# and is still owned by your organization.

Prevention

• Delete the DNS record before (or at the same time as) deleting the cloud resource. Put this in decommissioning checklists.
• Review DNS zones regularly and remove records nobody can explain.
• Assign owners to every subdomain.

Certificate Transparency trade-off

Every public TLS certificate is logged, so certificates reveal subdomain names like vpn. or jira.. Wildcard certificates (*.companyx.com) hide individual subdomain names from CT logs, but if a wildcard certificate’s private key is stolen, it can impersonate every subdomain. It’s a trade-off, not a free fix.

TXT Record and WHOIS Exposure

TXT records

dig TXT companyx.com +short

"v=spf1 include:spf.protection.outlook.com include:_spf.salesforce.com -all"
"google-site-verification=abc123..."
"atlassian-domain-verification=xyz789..."
"v=DMARC1; p=reject; rua=mailto:dmarc@companyx.com"

What to do:
- Remove stale verification tokens for services you no longer use. Check each vendor’s documentation first, since some require the record to stay for ongoing verification.
- Keep SPF, DKIM, and DMARC. They’re essential email security controls. Their presence is fine; accept that SPF reveals your email senders.

WHOIS/RDAP

• Use registrar privacy or redaction where appropriate.
• Use role-based contacts (for example, dns-admin@companyx.com) instead of a named employee’s email.

Employee Training and Social Media Policy

Employees are the largest and least controllable part of the attack surface. Training should be practical and positive, not “never post anything.”

Topics to cover:
- What not to post: badges, screens, whiteboards, office interiors that show security equipment, internal tool names, org charts, real-time executive travel.
- LinkedIn balance: it’s fine to be proud of your work, but a detailed list of every internal system you administer is a roadmap.
- Recognizing OSINT-driven attacks: fake recruiters, “survey” requests, vendor impersonation, and callers who already know a lot about the company.
- Reporting: make it easy to report suspicious contact.

A social media policy should include:
- What counts as confidential information
- Rules for photos taken at work
- Who can speak on behalf of the company
- How to handle requests from reporters, researchers, or “recruiters”
- Coverage for contractors and interns, not just full-time staff

Executive and VIP Protection

Executives, finance staff, IT administrators, and other high-value people get targeted more often:
- Business email compromise (BEC) and “whaling” emails impersonating executives
- Deepfake voice or video used to authorize fake payments
- Physical threats to people whose home addresses are easy to find

The Judge Esther Salas case (see 9.3-data-broker-opt-outs.md) shows why home addresses matter.

Protective measures:
- Company-sponsored data broker removal for executives and their families
- Home address scrubbing from public-facing sources where legally possible
- Family awareness: spouses’ and children’s social media can reveal addresses, schools, and travel
- Travel discipline: no real-time location posts; share travel plans on a need-to-know basis
- Separate public and private channels: a public contact route that doesn’t reach a personal phone
- Impersonation monitoring: fake executive profiles on social media and messaging apps
- Verification procedures: call-back verification on a known number for any payment or banking change, no matter who seems to be asking

Putting It Together

Key Terms

• External attack surface: everything about an organization that’s reachable or knowable from the internet.
• EASM (External Attack Surface Management): continuous discovery and monitoring of internet-facing assets.
• Shadow IT: technology used without the knowledge or approval of IT/security.
• Document metadata: hidden information stored inside files (author, software, paths).
• Secret scanning: automated detection of credentials in code and files.
• Push protection: blocking commits that contain secrets before they reach a repository.
• Dangling DNS record: a DNS record pointing to a resource that no longer exists.
• Subdomain takeover: claiming a dangling subdomain by recreating the resource it points to.
• BEC (Business Email Compromise): fraud that impersonates executives or vendors to redirect payments.

Key Takeaways

• Run authorized OSINT on your own organization before attackers do, and give every finding an owner.
• You can’t protect assets you don’t know about; build and maintain an inventory.
• Scrub document metadata and use real redaction, not black boxes.
• Write job postings with categories, not a full inventory of your security stack.
• Leaked secret? Rotate first; deleting the commit isn’t enough.
• Delete DNS records when you delete cloud resources to prevent subdomain takeover.
• Train employees on what not to post, and give executives extra protection.

References

• GitHub Docs: Push protection
• GitHub Docs: About secret scanning
• GitHub Changelog: Push protection available on public repositories for free (2023)
• GitHub Roadmap: Push protection enabled for users by default
• Gitleaks (GitHub)
• TruffleHog (GitHub)
• EdOverflow: Can I take over XYZ?
• Flare: Threat Exposure Management
• Wikipedia: Esther Salas