Seeker User & Administrator Guide

Seeker helps administrators locate sensitive or confidential information across file systems, Windows computers, network shares, databases, websites, Microsoft OneDrive, Microsoft SharePoint Online, public GitHub code, and NTFS folder permissions. Seeker also supports permanent Managed Seeker Agents for scanning Windows and macOS systems. This guide covers installation planning, scan configuration, targeting, reporting, scheduling, exclusions, storage, and troubleshooting.

New to Seeker? Start with Quick Start: Your First Scan, then review the scan method that matches the data source you want to assess.

Installation & Requirements

Managed Seeker Agents

Seeker supports permanent Managed Seeker Agents on Windows and macOS as an alternative to temporary dissolving-agent scans. Managed-agent deployments use three components:

• Seeker: The main application used to configure scans and review results.
• Seeker Agent Manager: The central service that manages enrolled agents, scan assignments, and communication with Seeker.
• Seeker Agent: A permanent background service installed on each Windows or supported Mac system to be scanned.

First install and configure Agent Manager, obtain its linking key, and create any groups you intend to use. Managed agents require administrative access for installation and enrollment, plus outbound HTTPS to Agent Manager, normally TCP 443.

Agent Requirements

Allow sufficient memory and free disk space for the scan workload. Managed agents also store pending results locally until delivery.

Windows Managed Agent – Install and Enroll

Starting with Windows Managed Agent 3.0.2, the EXE installer can install and enroll the agent in one command. Run from an elevated Command Prompt in the folder containing the installer:

Seeker-Agent-Setup-3.0.2.exe --manager sam.example.com --linking-key "YOUR-LINKING-KEY" --group "Windows Workstations"

For silent deployment with prerequisites already installed:

Seeker-Agent-Setup-3.0.2.exe /q /norestart --manager sam.example.com --linking-key "YOUR-LINKING-KEY" --group "Windows Workstations"

The prerequisite installers may still display dialogs when prerequisites are missing. Successful enrollment starts the Agent service. Installation without enrollment parameters and separate post-installation enrollment remain supported.

Mac Managed Agent – Install and Enroll

Install SeekerAgentMac-3.0.3.1.pkg, either interactively or from Terminal:

sudo installer -pkg "$HOME/Downloads/SeekerAgentMac-3.0.3.1.pkg" -target /

In System Settings > Privacy & Security > Full Disk Access, add and enable /Library/SeekerAgentMac/SeekerAgentMac. Use Command–Shift–G in the file picker to enter the path. Organizations can deploy this permission through an MDM PPPC profile.

Then enroll the Mac. Starting with Mac Managed Agent 3.0.3.1, the linking key can be supplied directly on the command line:

sudo /Library/SeekerAgentMac/seeker-agentctl enroll \
  --host sam.example.com \
  --name "Office Mac" \
  --group "Mac Workstations" \
  --linking-key "YOUR-LINKING-KEY"

The package installation and enrollment are separate commands; the linking key is passed to seeker-agentctl, not to the macOS package installer. The service runs automatically without a logged-in user.

For both platforms: Replace the example values with your organization’s settings. Group assignment is optional; omit --group when unnecessary. A specified group must already exist in Agent Manager. After enrollment, confirm the agent appears in Manager and belongs to the intended group.

Linking keys: Keys supplied on a command line can appear in process listings, command history, or deployment logs. For reduced exposure, use the separate standard-input enrollment methods described in the deployment guides.

Upgrades: Install the newer package over the existing installation; enrolled agents retain their identity and do not need to enroll again. The Windows installer skips supplied enrollment parameters when an existing enrollment is preserved.

Agent package versions are separate from the main Seeker and Agent Manager release numbers. Refer to the documentation included with each download for detailed deployment, certificate, and runtime requirements.

Remote Windows Targets – Dissolving Agent

The dissolving agent temporarily stages Seeker scanning components on the Windows target, scans files locally, and returns findings to the Seeker console. It does not require permanent-agent installation, Agent Manager enrollment, or a linking key.

The scanning account must have write/delete access to the target’s administrative share, such as \\target\c$, and permission to create remote processes through Windows Management Instrumentation (WMI).

Allow the required connectivity from the Seeker console to the target: SMB on TCP 445 and WMI/RPC on TCP 135 plus the applicable dynamic RPC ports, according to your organization’s policy.

The target must also be able to connect back to the Seeker console on TCP 443 to return results.

Endpoint security or application-control policies can block the temporarily staged scanning components. If remote execution fails, review the relevant security logs and confirm that the required access is permitted.

Remote Mac Targets – Dissolving Agent

The dissolving agent uses SSH and the Mac requirements listed above; it does not require permanent-agent installation, Agent Manager enrollment, or a linking key.

Enable Remote Login under System Settings > General > Sharing (on macOS Monterey, System Preferences > Sharing). Allow the scanning account to connect and authorize the required sudo commands without interactive prompts, according to your organization’s policy.

For protected user data, enable Allow full disk access for remote users in Remote Login settings. See Apple’s Remote Login instructions.

Content Extraction Prerequisites

Seeker uses dedicated parsers for some formats and registered Windows IFilters for many document types. Microsoft Access files require a compatible Access Database Engine/ACE or Jet provider. After installation—and after changing Office, Access engines, or IFilters—use Tools > Test Scanning for File Types to verify that formats important to your environment can be read.

Tip: A successful prerequisite test confirms that Seeker can extract the expected sample content with the currently installed provider/filter. It does not guarantee that every real-world document is readable; encrypted, damaged, locked, unusually large, or malformed files can still generate scan warnings.

Identity and Data Locations

Much of Seeker’s configuration and protected local state is tied to the Windows profile that configures and runs it. This is especially important for scheduled scans. Avoid configuring Seeker under a temporary administrator profile if another account will own normal operations.

• %LOCALAPPDATA%\Seeker contains the default SQLite database, configuration, saved target lists, and other per-user state.
• %PROGRAMDATA%\Seeker can contain shared application/license data.
• Scheduled scans should run under the intended Seeker operating account so they have access to that user’s configuration, protected credentials, certificates, and local schedule definitions.

Back to top

Quick Start: Your First Scan

1. Open Seeker under the account that will normally operate it.
2. Confirm licensing. Use Help > License if you need to import or review a license.
3. Choose the result back end. SQLite is the simplest default. If your deployment uses SQL Server, configure it under Data > Select Back-End Database Type.
4. Test file extraction. Run Tools > Test Scanning for File Types and resolve missing providers or filters that matter to your scan.
5. Review Search Patterns. Start with the shipped selections and test any custom regular expressions on representative data.
6. Review Scan Settings. Check extensions, path filters, path/permission alerts, PDF page limit, target timeout, result detail, row/page caps, and Fast/Slow scan speed.
7. Choose a small, controlled target first. Validate credentials, firewall access, extraction, and detection behavior before scanning an entire enterprise OU or large file share.
8. Select the scan type and targets, then run the scan. Monitor the Scan Progress window.
9. Review both the Report and Logs tabs. An individual file, table, directory, or URL can fail while the rest of the target continues successfully.
10. Validate sample findings at the source. Confirm the pattern, masking, path alerts, and permission information are behaving as intended.
11. Save reusable targets/configuration. After the interactive workflow is proven, consider scheduling it.

Use exclusions carefully. Adding a Path/Hash exclusion removes matching historical findings from Seeker’s stored results as well as suppressing future matching findings. Removing the exclusion later does not reconstruct the deleted historical rows. See Managing Exclusions.

Back to top

Available Scan Types

The Targets and Scan Type tab provides the current production scan modes. Changing scan type can clear the current target list because different scan modes use different target formats.

Back to top

Selecting Scan Targets

Active Directory OU and Computer Selection

1. On Targets and Scan Type, choose Browse Active Directory to Select OUs and/or Machines.
2. Navigate the directory tree and select the required OUs, containers, and/or computer objects.
3. When returning computers through an OU, you may filter by machine-name prefix or substring and, in the interactive browser, optionally limit indirectly discovered machines to systems active within the last 90 days.
4. Return the machine list to Seeker, review the potential targets, and add the desired systems to the confirmed target list.

Disabled computer accounts are filtered from directory enumeration. Explicitly selected computer objects are handled separately from the optional 90-day filter applied to machines discovered beneath an OU.

Active Directory Group

1. Choose Select Active Directory Group with Targets.
2. Enter the group name and validate it.
3. Add the returned computer members to the confirmed target list.

The current group-targeting workflow returns direct computer members; do not rely on it to recursively expand nested groups.

Browse for a Folder

1. Choose Browse for a Root Folder to Scan.
2. Select the local or network folder.
3. When prompted, choose whether the selected folder itself, its immediate subfolders, or folders two levels below should become individual targets.
4. Review and add the resulting target(s).

Splitting a large root into separate subfolder targets can improve parallel processing.

Manual UNC Path, Machine Name, IP Address, or URL

For applicable scan types, use the single-target entry control and enter the required UNC path, machine name, individual IP address, or website URL. Website targets must be absolute http:// or https:// URLs.

Target-file format: A target file is one target per line. It is not parsed as a structured comma-separated CSV. Seeker does not expand CIDR notation, subnets, wildcard hosts, or IP ranges; generate the individual targets first and place one on each line.

For network file scans, prefer UNC paths such as \\server\share rather than mapped drive letters. Mapped drives can resolve differently under alternate credentials or scheduled-task identities.

Saved Target Lists

Use File > Save Scan Targets, Load Scan Targets, and Delete Saved Target Lists to manage reusable Seeker target-list files. This is separate from importing a plain one-target-per-line text file generated by another tool.

Back to top

Search Patterns & Detection

The Search Patterns tab controls the expressions Seeker uses to identify potential sensitive information. Each pattern can include a friendly name, a regular expression, an optional validator, and an optional companion expression.

Built-in and Custom Patterns

Seeker ships with patterns for common sensitive-data types and lets administrators add their own regular expressions. Shipped validators include Social Security numbers, several payment-card types, generic Luhn validation, ABA routing numbers, IBAN, Australian TFN, Brazilian CPF/RG, and Hong Kong ID.

Test custom regular expressions before broad scans. Complex or poorly constructed regular expressions can be computationally expensive. Validate new expressions against representative sample content before using them across large target sets.

Companion Expressions

A companion expression can reduce false positives by requiring additional context. For normal file scans, the companion can match the path/name or appear near the primary match in extracted content. For example, an eight-digit medical record number pattern could require a nearby value such as MRN.

For relational database scans, companion context is broader: it can be satisfied by the database/target, table, current field value, or column names in the row.

Match Detail and Masking

• Display matching text controls whether stored result details contain matching values or positions.
• Single vs. multiple instances changes the number of examples shown, not the total match count.
• Display surrounding text can include nearby content that was not itself matched; enable it only when the additional exposure is acceptable.
• Display only last four masks supported SSN/payment-card/Hong Kong ID validator results; it is not universal redaction for every custom pattern.

File Content Extraction

Seeker uses dedicated processing for PDF and Access data and specialized paths for ZIP/PST/OST when those extensions are enabled. Many other document types are extracted using registered Windows IFilters. When no IFilter is available for an ordinary format, Seeker can fall back to a limited raw-text read.

Back to top

Scan Settings

The Scan Settings tab controls extraction limits, file extensions, false-positive controls, website limits/authentication, database row limits, path filters/alerts, permission alerts, result detail, target timeout, and scan parallelism.

Path Filters vs. Path Alerts vs. Result Exclusions

Back to top

Scan Method Guides

Back to top

Permission Analysis

Seeker has two related permission capabilities:

1. Permission alerts attached to ordinary content findings, which can flag sensitive files accessible to selected Windows principals.
2. Folder Permission Check, which analyzes directory ACL structure without scanning content.

Permission Alerts on Content Findings

When enabled, Seeker evaluates the Windows ACL of matching files. The shipped configuration includes alerting for Authenticated Users and Everyone, and administrators can add other users/groups. You can also request the complete allowed ACL instead of only configured alert principals.

Explore Permissions

The permission explorer provides a hierarchical folder tree plus an ACL grid. Current controls include:

• Depth — choose how many folder levels to analyze/display.
• Hide Inherited — focuses the child-folder presentation on permission changes while retaining the selected root as a baseline.
• Minimum Users — filters toward principals estimated to expose a folder to at least the selected number of users.
• Folder ACLs Only — the current exploration workflow is folder-oriented.
• Excel/CSV export — export the permission dataset for further review.

The grid can show principal, SID, Allow/Deny, Read, Write, Modify, Full, inheritance status, and detailed rights. Unresolved SIDs are retained for investigation rather than silently discarded.

Interpretation note: Permission exploration is an ACL/exposure analysis, not a complete simulation of every user’s effective Windows access token. Deny entries, inheritance order, nested groups, share permissions, inaccessible directory services, conditional access, and other factors can affect effective access.

Back to top

Results & Reporting

Scan findings are stored automatically in the selected Seeker result back end and are displayed on the Report tab. Warnings and errors are shown separately on the Logs tab.

Standard Result Fields

Summary reporting can include total detection instances, distinct items with detections, matching files/items by type, matching patterns by type, and top targets. Remember that a single file can match multiple patterns and a single pattern can occur multiple times, so file counts, finding counts, and detection-instance counts are not expected to be identical.

Historical Scans

• File > Load Saved Scan Results loads findings and logs from a stored scan instance.
• File > Delete Scan Results permanently deletes the selected run’s stored result, error, target-status, and metadata records. It does not modify source files or source databases.
• Interrupted multi-target scans can use stored target-completion status to continue without deliberately rerunning targets already recorded as complete for that scan instance.

Logs

An error does not necessarily mean an entire target failed. Seeker can log an inaccessible directory, unreadable file, parser error, database row/table problem, timeout, or web request failure while continuing other work. Review Logs whenever expected findings are missing.

Back to top

Saving, Importing & Reusing Configuration

Save the Current Configuration

Use File > Save Config to save the current Seeker settings for the current Windows user.

Export Configuration

1. Choose File > Export Config.
2. Select the destination and file name.
3. Save the generated Seeker configuration XML.

Import Configuration

1. Choose File > Import Config.
2. Select a Seeker-generated configuration XML file.
3. Open it to load those settings.

Restore Installation Defaults

Choose File > Restore Default Config.

Configuration export is not a complete machine migration. Scan targets, saved target-list files, credentials, license files, back-end selection, installed IFilters/providers, and Windows Task Scheduler entries are separate from the exported configuration XML.

Back to top

Scheduling & Command-Line Operation

After an interactive scan is configured and tested, Seeker can save supported scan definitions and run them through Windows Task Scheduler using SeekCL.exe.

Create a Scheduled Scan

1. Configure the patterns, Scan Settings, scan type, targets, credentials, and any desired export behavior.
2. Choose Schedule This Scan from the Targets and Scan Type tab, or Add Scheduled Scan with Current Properties from Scheduled Scans.
3. Enter a scan name.
4. For supported network target types, choose Static Target List or Dynamic Target List.
5. Choose a Daily, Weekly, or Monthly schedule.
6. Provide the scan credentials and the current Windows account password needed to register/run the scheduled task.
7. Optionally configure automatic result export.

Static vs. Dynamic Active Directory Targets

Static stores the explicit target list as it existed when the schedule was saved. Dynamic stores selected AD OU/container locations and re-enumerates enabled computer objects each time the scheduled scan runs, so newly added or removed machines are reflected automatically.

The interactive AD browser can optionally filter indirectly discovered computers to machines active within the last 90 days. Dynamic scheduled enumeration does not apply that interactive 90-day filter; it re-enumerates currently enabled computers in the stored OU/container locations.

Edit an Existing Scheduled Scan

From the Scheduled Scans tab you can:

• Set scan credentials.
• Update the Windows scheduled-task password.
• View or change the schedule.
• Load the scan’s targets/settings into the main console.
• Save the current targets/settings back into the scheduled definition.
• Configure automatic export.
• Delete the scheduled scan.

If the Windows password for the account that runs a scheduled scan changes, update the scheduled-task password in Seeker. A scan that works interactively but fails when scheduled should be checked for Task Scheduler identity, password, profile access, network rights, and access to the same Seeker per-user data.

Microsoft OneDrive, SharePoint, and GitHub Credential Scan are interactive in the current production workflow and are not offered as scheduled scans.

Command Line

SeekCL.exe runs a scan definition that was previously created/saved by Seeker; it is not a separate command-line configuration system.

SeekCL.exe Scan_Name [-D] [-E "C:\Export\Path"]

Example:

"C:\Program Files\Seeker LLC\Seeker\SeekCL.exe" AccountingFileShares -E "C:\SeekerExports"

Scheduled/command-line exports use the scan name and timestamp to distinguish individual runs.

Back to top

Managing Exclusions

Exclusions are useful for findings that have been reviewed and accepted as false positives or legitimate business requirements. They are separate from path filters: filters prevent scanning, while result exclusions operate on stored findings.

Important — exclusions affect historical data. When you add a Path, Hash, or Path-or-Hash exclusion, Seeker immediately deletes stored findings that match the new exclusion and suppresses matching findings from future scans. If you later delete the exclusion, those previously deleted historical findings are not restored; only future matching findings can appear again. Back up or obtain approval before applying exclusions where historical evidence must be preserved.

Exclude a Finding

1. In the Seeker report, click the applicable Path or Hash to open Manage Detection.
2. Choose the exclusion criteria: Path, Hash, or Path OR Hash.
3. Select a reason such as False Positive, Business Requirement, or Other.
4. Confirm the exclusion.

Review or Remove Existing Exclusions

1. Open Data > Manage Exclusions.
2. Review the exclusion list and delete an exclusion when it should no longer suppress future findings.

Back to top

Selecting & Maintaining the Result Back End

SQLite

SQLite is Seeker’s default local result back end and resides in the current user’s Seeker data directory. It is the simplest choice for a local/single-console deployment.

Microsoft SQL Server

Use Data > Select Back-End Database Type to select SQL Server, enter the server/port information, and test the connection. Seeker uses Windows integrated authentication for its SQL Server result database. The identity performing initial setup must have sufficient rights if Seeker needs to create the database/tables; routine operation should use only the read/write permissions Seeker requires.

Migrating Existing Data

When switching to SQL Server, Seeker can migrate core result data. Current migration includes:

• Scan results
• Scan metadata
• Scan target status/continuation data
• Exclusions

Not everything moves to SQL Server. The local error/log table and scheduled scan definitions are not part of this migration. Scheduled definitions remain in the current user’s local SQLite data because SeekCL.exe uses that local store. Back up Seeker’s local data before migration and do not delete the local database merely because finding migration succeeded.

Compact the SQLite Database

When SQLite is the active back end, use Data > Compact Database (SQLite) to reclaim unused database space. Close scan/report activity first and ensure the drive has free space at least as large as the current database. The Seeker UI may appear unresponsive while compaction is running; do not interrupt it unnecessarily.

Back to top

Troubleshooting

Start with the least destructive diagnostics:

1. Record the Seeker version, scan type, scan name/instance, target, Windows identity, time, and exact error.
2. Review the Logs tab before deleting log/error data.
3. Reproduce against one small representative target using the same identity and settings.
4. Use Tools > Test Scanning for File Types for extraction/provider problems.
5. Enable Debug Mode only long enough to reproduce a problem. Treat debug files as potentially sensitive.
6. Back up Seeker’s local data and databases before repair, migration, or compaction work.

Back to top

Network & Port Reference

Firewall guidance: Verify the effective firewall rules in the actual deployed environment rather than assuming installation has opened every required path. In particular, remote Windows scanning requires targets to reach the Seeker console on TCP 443 in addition to the console reaching targets over SMB/WMI/RPC.

Back to top