User Guide

🚀Deploy AgentsInstall and roll out SecuritySnares across your environment🔔Reviewing AlertsUnderstand and respond to ransomware detections🔄File RecoveryRestore files encrypted during an incident💚Agent HealthMonitor and manage agent status across devices🛡️Agent ModesSwitch between Alert-Only and Protect modes🔧TroubleshootingFix common installation and agent issues🗑️UninstallingSafely remove the SecuritySnares agent🔐Single Sign-OnConfigure SSO with Azure AD, Google, or Okta🔗Webhook NotificationsConfigure and receive real-time alert webhooks⬆️Agent UpdatesKeep SecuritySnares agents up to date

Introduction

Welcome to the User Guide for SecuritySnares, a state-of-the-art security solution designed to protect your digital assets from ransomware threats. This document outlines best practices to ensure a smooth and effective deployment of SecuritySnares within your organization.

Purpose

The primary purpose of this guide is to provide step-by-step instructions and best practices for troubleshooting SecuritySnares in a way that maximizes its effectiveness and minimizes disruptions to your business operations.

Scope

This technical guide provides detailed instructions for configuring, troubleshooting, and maintaining SecuritySnares deployments.

Topics Covered:

• Installation and deployment across various platforms
• Configuration and customization for organizational needs
• Alert management and response procedures
• Common troubleshooting scenarios and solutions
• Performance optimization and best practices

This guide empowers technical professionals to maximize SecuritySnares' effectiveness in detecting and preventing ransomware threats.

Overview of SecuritySnares Product

SecuritySnares is a small, agent-based prevention technology that identifies files being encrypted on the file system. The algorithm is a two step process:

1. Identify encryption of data to the hard drive (filesystem)
2. Determine if the process is a known, trusted process

Once encryption is identified, the process is evaluated to understand its use. The process will either be labeled "trusted" if it should be performing encryption, or "untrusted" if it is unknown if it should be performing encryption. When operating in Protect mode, if the process status is unknown, SecuritySnares will terminate the process to prevent potential ransomware activity.

Target Audience

This guide is designed for technical professionals responsible for deploying and managing SecuritySnares:

• System Administrators
• Network Engineers
• IT Support Staff
• Managed Service Providers (MSPs)
• Security Operations Center (SOC) Analysts

The guide assumes familiarity with Windows administration, networking concepts, and enterprise software deployment tools.

Performance Characteristics

SecuritySnares is designed for minimal performance impact on production systems.

Performance Metrics (measured during active ransomware simulation on heavily utilized SQL server):

• CPU Usage: 0.02% average
• Memory: Maximum 50MB
• Disk I/O Latency: Maximum 44KB/sec additional latency

Performance Notes:

• Brief CPU spikes occur when encryption activity triggers SecuritySnares analysis
• CPU returns to idle after process evaluation completes
• Performance impact is negligible even on heavily utilized systems

Understanding SecuritySnares

Architecture

Agents are installed on endpoint machines. Management of agents is primarily done through the web application.

Central to the system is the Agent, a lightweight kernel-mode filesystem driver installed on endpoint devices. It is responsible for evaluating filesystem input/output (I/O), running SecuritySnares's algorithm to identify encryption. Once encryption is identified, the driver will further perform evaluation of the process. Some processes are able to be evaluated for their trustworthiness locally on the machine without Internet connection.

The SecuritySnares' Web Portal acts as a management and reporting console. It is developed in an API-first methodology and is designed to be used programmatically. The SecuritySnares API provides any Internet-connected agent with Threat Intelligence. The Threat Intelligence repository contains analysis of over 3.5 billion executable processes. Here, every process undergoes rigorous examination to determine its trustworthiness, allowing the Threat Intelligence API endpoint to respond with a classification of either trusted or untrusted.

Within the web app, Agents are assigned to an Organization through the use of an API Key. Organizations can belong to a Managed Service Security Provider (MSSP). A MSSP is able to impersonate their customer Organizations to review alerts, configure and deploy agents, and review the overall health of the customer.

Deploy Agents

System Requirements

Supported Operating Systems:

• Windows 10 and later (64-bit)
• Windows Server 2016 and later (64-bit)

Software Requirements:

• .NET Runtime version 6
• The self-contained .exe installer includes .NET and will install it automatically if not present

Hardware Requirements:

• CPU: Minimal impact (0.02% average utilization)
• RAM: ~50MB at runtime. The installer also performs an available-RAM preflight check before installation begins; see Pre-Flight Checks.
• Disk Space: 200MB for installation and backup storage. The installer also performs a free-disk-space preflight check before installation begins; see Pre-Flight Checks.
• Disk I/O: Maximum latency addition of 44KB/sec

Pre-Flight Checks

Before installation begins, the .exe bootstrapper and the underlying MSI both verify that the host meets the minimum free-disk and available-RAM thresholds. If either check fails, installation stops with guidance rather than failing mid-install.

Use the .exe flags when invoking SecuritySnares-Agent.exe. If your deployment tooling injects MSI public properties directly, use the matching MSI property names below.

Preflight threshold	Default	.exe installer flag	MSI property
Free disk space on the target drive	500 MB	--min-disk-mb=<N>	PREFLIGHT_MIN_DISK_MB=<N>
Available physical memory	128 MB	--min-ram-mb=<N>	PREFLIGHT_MIN_RAM_MB=<N>

Example overrides:

SecuritySnares-Agent.exe /S API_URL=https://api-prod.securitysnares.com API_KEY=YOUR_API_KEY_HERE --min-disk-mb=150 --min-ram-mb=64

Lower these thresholds only for tightly provisioned systems where you have confirmed the host still has enough room and memory for installation and normal agent operation.

Network Connectivity (Optional)

SecuritySnares operates effectively in isolated environments (such as OT/ICS networks) without network connectivity. However, network connectivity provides additional benefits:

Benefits of Network Connectivity:

• Centralized management and monitoring via the web portal
• Access to Cyber Threat Intelligence database with 3.5+ billion known-good executables
• Remote configuration and policy management
• Automated agent updates
• Centralized alert aggregation

Network Requirements for Connected Deployments:

If network connectivity is available, the agent requires outbound HTTPS access:

• Domain: *.securitysnares.com
• Primary API Endpoint: https://api.securitysnares.com
• Validation Endpoint: https://validate.securitysnares.com
• Port: 443 (HTTPS)
• Protocol: TLS 1.2 or higher (TLS 1.3 supported on legacy Windows via libcurl)

Firewall Configuration:

Ensure your firewall allows outbound connections to *.securitysnares.com. No inbound ports need to be opened on endpoint machines.

Proxy Support:

SecuritySnares respects system proxy settings configured in Windows.

Self-Hosted Mode:

For completely isolated environments, SecuritySnares can operate in self-hosted mode where it performs local threat analysis without communicating with the cloud portal. Contact a SecuritySnares representative to discuss the self-hosted solution.

Download

Download the agent from https://portal.securitysnares.com/downloads.

The Agent web page will provide the correct API URL and API Key needed in the next step.

Please note the API Key should be the API Key from https://portal.securitysnares.com/downloads.

Manual Installation

Step-by-step Installation Process:

1. Download the Installer

   • Navigate to https://portal.securitysnares.com/downloads
   • Download the self-contained .exe installer
   • The file is named install-ransomsnare-<VERSION>-x64-net10.exe, where <VERSION> is the current release (e.g. install-ransomsnare-2.0.2.0-x64-net10.exe). Substitute the actual filename in the commands below.

2. Gather Installation Credentials

   • Locate your API Key from the Downloads page
   • Note the API URL (default: https://api.securitysnares.com)

3. Run the Installer

   • Execute the downloaded installer with administrator privileges
   • Before files are copied, the installer runs the checks described in Pre-Flight Checks
   • When prompted, enter the API URL (use the default for cloud-hosted deployments)
   • Enter your organization's API Key

4. Verify Installation

   • Check that the SecuritySnares service is running in Windows Services
   • Confirm the agent appears in the web portal at https://portal.securitysnares.com/agents
   • Verify the "Last Updated" timestamp is recent (indicates successful communication)

Installation Exit Codes:

• 0 = Successful installation
• Non-zero = Installation failure (check installation logs for details)

Automated Deployment

The SecuritySnares installer is a self-contained .exe that includes the .NET runtime. All automated deployment methods use this .exe installer with silent installation flags.

Silent Installation Command:

install-ransomsnare-<VERSION>-x64-net10.exe /q API_URL=https://api.securitysnares.com API_KEY=YOUR_API_KEY_HERE

For preflight thresholds and override mappings, see Pre-Flight Checks.

Parameters:

• /q - Silent mode (no user interaction)
• API_URL - SecuritySnares API endpoint (default: https://api.securitysnares.com)
• API_KEY - Your organization's API key from the Downloads page
• --skip-api-key-check - Skip API key validation during installation. Use this when deploying to environments where Internet connectivity is limited or unavailable. Warning: Only use this parameter if you are certain your API key is correct or if directed to do so by SecuritySnares personnel. Skipping validation may result in agents that cannot communicate with the SecuritySnares platform.
• --min-disk-mb=N - Override the installer's minimum free-disk preflight check (default: 500 MB). The check measures free space on the target drive before installation starts. Lower this only for tightly provisioned systems where you have confirmed the host still has enough room for installation, logs, and backups.
• --min-ram-mb=N - Override the installer's minimum available-RAM preflight check (default: 128 MB). The check measures free physical memory and stops the install if it is below the threshold, guarding against deploying onto a critically low-memory host. Lower this (e.g. --min-ram-mb=64) only if you understand the host's memory state.
• Exit code 0 indicates successful installation

Installation via SCCM

1. Create the Content Source

   • Copy the install-ransomsnare-<VERSION>-x64-net10.exe installer to a network share accessible by your SCCM distribution points (e.g., \\sccm-server\sources\SecuritySnares\)

2. Create an Application in SCCM

   • Open the SCCM Console and navigate to Software Library → Application Management → Applications
   • Click Create Application
   • Select Manually specify the application information
   • Provide a name (e.g., "SecuritySnares Agent") and click through to the deployment type

3. Configure the Deployment Type

   • Select Script Installer as the deployment type
   • Content location: Point to the network share containing the installer
   • Installation program:

     install-ransomsnare-<VERSION>-x64-net10.exe /q API_URL=https://api.securitysnares.com API_KEY=YOUR_API_KEY_HERE

   • Uninstall program:

     "C:\Program Files\SecuritySnares\RansomSnare.Agent.exe" -uninstall UNINSTALL_TOKEN

   • Installation behavior: Install for system
   • Logon requirement: Whether or not a user is logged on

4. Configure the Detection Method

   • Select File System detection rule
   • Type: File
   • Path: C:\Program Files\SecuritySnares
   • File name: RansomSnare.Agent.Service.exe
   • Check This file or folder is associated with a 32-bit application on 64-bit systems: No

5. Distribute and Deploy

   • Distribute content to your distribution points
   • Deploy the application to the target device collection
   • Set the deployment purpose to Required for automatic installation

Installation via PowerShell

# Download and install SecuritySnares
$apiKey = "YOUR_API_KEY_HERE"
$apiUrl = "https://api.securitysnares.com"
$installerPath = "C:\Temp\install-ransomsnare-<VERSION>-x64-net10.exe"

# Silent installation
Start-Process -FilePath $installerPath -ArgumentList "/q", "API_URL=$apiUrl", "API_KEY=$apiKey" -Wait

Installation via Group Policy (GPO)

GPO software installation natively supports MSI packages only. To deploy the SecuritySnares .exe installer via GPO, use a startup script:

1. Copy the install-ransomsnare-<VERSION>-x64-net10.exe installer to a network share accessible by all target computers (e.g., \\dc\netlogon\SecuritySnares\)
2. Create a PowerShell deployment script (Deploy-SecuritySnares.ps1):

   # Deploy-SecuritySnares.ps1
   # Skip installation if SecuritySnares is already installed
   if (Test-Path "C:\Program Files\SecuritySnares\RansomSnare.Agent.Service.exe") {
       exit 0
   }
   
   $installerPath = "\\dc\netlogon\SecuritySnares\install-ransomsnare-<VERSION>-x64-net10.exe"
   Start-Process -FilePath $installerPath -ArgumentList "/q", "API_URL=https://api.securitysnares.com", "API_KEY=YOUR_API_KEY_HERE" -Wait

3. Create a new GPO or edit an existing one
4. Navigate to: Computer Configuration → Policies → Windows Settings → Scripts → Startup
5. Add the PowerShell script
6. Link the GPO to the target Organizational Unit (OU)

Installation via Microsoft Intune

1. Prepare the Win32 App Package
   • Download the Microsoft Win32 Content Prep Tool
   • Package the installer (the resulting .intunewin will share the installer's base name — e.g. install-ransomsnare-2.0.2.0-x64-net10.intunewin):

     IntuneWinAppUtil.exe -c "C:\source\SecuritySnares" -s "install-ransomsnare-<VERSION>-x64-net10.exe" -o "C:\output"

2. Navigate to Apps → Windows in the Intune portal
3. Click Add and select Windows app (Win32)
4. Upload the generated .intunewin file
5. Configure the install and uninstall commands:
   • Install command:

     install-ransomsnare-<VERSION>-x64-net10.exe /q API_URL=https://api.securitysnares.com API_KEY=YOUR_API_KEY_HERE

   • Uninstall command:

     "C:\Program Files\SecuritySnares\RansomSnare.Agent.exe" -uninstall UNINSTALL_TOKEN

6. Configure detection rules:
   • Rule type: File
   • Path: C:\Program Files\SecuritySnares
   • File or folder: RansomSnare.Agent.Service.exe
   • Detection method: File or folder exists
7. Assign to target device groups

Uninstallation

To prevent tampering by malicious actors, the SecuritySnares agent requires a token for uninstallation. This is configured in the web-based management console. This token is unknown to SecuritySnares. A customer must ensure they have it.

If going through the GUI, the user would be prompted for the uninstall token.

The agent uninstallation can be performed programmatically by invoking the following:

C:\Program Files\SecuritySnares\RansomSnare.Agent.exe -uninstall [uninstall token]

Agent Health

SecuritySnares provides three complementary health views:

• Security Dashboard for organization-wide protection posture, version coverage, and recent activity
• Fleet Health for a one-row-per-agent operational view
• Agent-Level Health for drilling into CPU and memory attribution on a single host

Security Dashboard

Navigate to Dashboard in the left navigation. The timestamp in the upper-right corner shows when the dashboard was last refreshed.

Protection posture

The Protection posture section is a live snapshot of the current fleet state. It is not affected by the timeframe selector lower on the page.

• Protect mode counts endpoints that are currently checking in and enforcing protection.
• Alert-only counts endpoints that are checking in but monitoring only.
• Offline / stale counts endpoints that have not checked in for more than 24 hours. These endpoints are counted separately because they are not actively reporting.
• Click Review endpoints to open the Agents page. Click the alert-only or offline chips to open filtered agent lists.

Agent versions

The Agent versions card is also live and shows how many endpoints report each installed version.

• Up to date means at least 90% of endpoints are on the current release.
• Update available means some endpoints are behind the current release.
• Release info unavailable means the portal could not confirm the current release from the update channel. Reported versions are still shown, but current-vs-behind comparison is temporarily unavailable.

Use What's new to review the changelog. Use Update agents to jump to the Agents page, then follow Agent Updates.

Activity and Trend

Use Last 24 hours, Last 7 days, Last 30 days, Last 90 days, or a Custom range to change only the Activity and Trend sections. Protection posture and Agent versions always show the current fleet state.

• Processes evaluated: processes inspected before they ran
• Reputation checks: file-reputation lookups
• Alerts raised: all alerts in the selected window, with actioned alerts and dismissed false positives called out separately
• Threats blocked: alerts where SecuritySnares killed the process in Protect mode; ransomware and WiperSnare events are tracked separately

The Trend chart plots processes evaluated and reputation checks over time.

Processes evaluated and reputation checks are reported only by agents on current telemetry. Older agents are not yet counted, so these totals are conservative.

Fleet Health

Navigate to Fleet Health in the left navigation for a one-row-per-agent operational view.

Use Search hostname to filter rows and Refresh to request an immediate refresh. Rows can be sorted by Hostname, Last metric, Agent memory, or Agent CPU.

The customer Fleet Health table shows:

• Hostname: click a hostname to open the per-host drill-down
• Last metric: when the portal last received telemetry from that agent. A stale chip means no metrics have been received for more than 15 minutes
• Agent memory: the agent's average memory usage on that host
• Agent CPU: the agent's average CPU share on that host

Fleet Health is the fastest way to find hosts that are no longer reporting, or hosts where the SecuritySnares process is using more CPU or memory than expected.

Agent-Level Health

Open Agent-Level Health by clicking a host in Fleet Health.

The header summarizes the host and the selected time window, including hostname, organization, last-metric time, agent version, operating system, driver version, monitored drives, worker-process count, and installed RAM. A live indicator shows whether telemetry is actively arriving.

Use the 24h, 7d, or Custom selector to change the analysis window. The page includes:

• Resource Attribution Summary: a plain-language summary of how much memory and CPU the SecuritySnares agent used on that host during the selected window
• Agent-Level Health KPI tiles: average agent memory, share of installed RAM, share of memory currently in use, average agent CPU, and share of total CPU consumption
• Memory and CPU charts: time-series views showing the SecuritySnares agent compared with host capacity or the rest of the system

On older telemetry, the page may show a limited-data view instead of full attribution. In that case, SecuritySnares still shows system-level CPU, memory, and disk charts, but resource-attribution and deeper diagnostic panels are not available until the agent is updated.

Reviewing Alerts

Alerts are presented on https://portal.securitysnares.com/alerts.

On this page, analysts are presented with the metadata surrounding the suspicious event. The Process File Path is the suspicious process attempting to encrypt files. The suspicious process can be downloaded by clicking "Download Quarantined File". The file will be downloaded as a password protected zip file. The password is 'infected'.

Should the event be a false positive, analysts are able to Dismiss Alert, or create an entry in the Allow List by clicking Allow. It is strongly recommended to allow processes by their full file path to reduce the potential for allowing a malicious process to execute. The next preferred allow-list method is by checksum, though this method does not handle software updates.

File Recovery Process

When SecuritySnares detects and terminates a suspicious process in Protect mode, it automatically initiates file recovery to restore encrypted files:

How File Recovery Works:

1. Backup Creation: SecuritySnares maintains backups of files before they are modified by any process. These backups are stored in C:\ProgramData\SecuritySnares\Backup

2. Process Termination: When an untrusted process is detected encrypting files, SecuritySnares terminates the process and all child processes

3. Automatic Recovery: SecuritySnares automatically recovers files that were encrypted by the terminated process from the backup folder

4. Recovery Queue: The recovery process tracks which files were modified by which process, ensuring only affected files are restored

5. Backup Retention: Backups are managed automatically, with write access to the backup folder restricted to prevent tampering

Important Notes:

• File recovery only occurs in Protect mode
• In Alert-Only mode, backups are not created to minimize performance impact
• The backup folder is protected by the driver to prevent malicious modification or deletion

Windows Event Log Integration

By default, SecuritySnares writes alerts to the Windows Event Log. This allows for seamless integration with SIEM technologies and centralized monitoring solutions.

• Event ID: 739
• Location: System Event Log

If your organization is collecting Windows Event Logs, you are already configured for centralized alert monitoring!

Microsoft Sentinel Integration

SecuritySnares supports two complementary ways to get alert data into Microsoft Sentinel. You can use either or both:

1. Windows Event Log forwarding — agents write detection events to the local Windows Event Log, which the Azure Monitor Agent collects into your Sentinel workspace.
2. Direct webhook ingestion — SecuritySnares webhook alerts are forwarded by an Azure Logic App into a custom Log Analytics table, giving you the full structured alert payload (process hashes, parent process, action taken, AI threat analysis, and more).

Method 1 — Windows Event Log forwarding

To ingest SecuritySnares events through the Windows Event Log, configure your data collection with the following XPath query:

System*[System[(EventID=739)]]

This ensures that Event ID 739 is captured and ingested into your Sentinel workspace for analysis and alerting.

Method 2 — Direct webhook ingestion via Azure Logic App

This method forwards the complete SecuritySnares alert payload to a custom log table named SecuritySnares_CL in your Log Analytics workspace, so every alert field is available for hunting, analytics rules, and workbooks.

Prerequisites

• A Log Analytics workspace connected to Microsoft Sentinel.
• Permission to create a Logic App and an API connection in your Azure subscription.
• A SecuritySnares account with access to webhook configuration.

Step 1 — Create the Logic App

Create a Consumption-plan Logic App in the same region as your workspace. When prompted, add an Azure Log Analytics Data Collector API connection using your workspace ID and primary key (found under your Log Analytics workspace → Agents / Agents management).

Step 2 — Import the workflow definition

Open the Logic App in Code view and paste the workflow definition below. It exposes an HTTP trigger, parses the SecuritySnares payload, stamps TimeGenerated from the alert's alert_time (falling back to the current UTC time), and posts the record to Log Analytics under the SecuritySnares log type.

{
  "definition": {
    "$schema": "https://schema.management.azure.com/providers/Microsoft.Logic/schemas/2016-06-01/workflowdefinition.json#",
    "contentVersion": "1.0.0.0",
    "triggers": {
      "When_an_HTTP_request_is_received": {
        "type": "Request",
        "kind": "Http",
        "inputs": {
          "schema": {
            "type": "object",
            "properties": {
              "entity_id": { "type": "string" },
              "organization_name": { "type": "string" },
              "webhook_version": { "type": "integer" },
              "alert_id": { "type": "string" },
              "hostname": { "type": "string" },
              "process_name": { "type": "string" },
              "process_id": { "type": "string" },
              "process_file_path": { "type": "string" },
              "process_md5": { "type": "string" },
              "process_sha256": { "type": "string" },
              "parent_process_id": { "type": "string" },
              "parent_process_file_path": { "type": "string" },
              "parent_process_md5": { "type": "string" },
              "parent_process_sha256": { "type": "string" },
              "attempted_file_encryption": { "type": ["string", "null"] },
              "ip_address": { "type": "string" },
              "mac_address": { "type": "string" },
              "action_taken": { "type": "string" },
              "alert_time": { "type": "string" },
              "ai_threat_analysis": { "type": ["string", "null"] }
            }
          }
        }
      }
    },
    "actions": {
      "Parse_JSON": {
        "type": "ParseJson",
        "inputs": {
          "content": "@triggerBody()",
          "schema": { "type": "object" }
        },
        "runAfter": {}
      },
      "Send_Data": {
        "type": "ApiConnection",
        "inputs": {
          "host": {
            "connection": {
              "name": "@parameters('$connections')['azureloganalyticsdatacollector']['connectionId']"
            }
          },
          "method": "post",
          "body": "@createArray(setProperty(body('Parse_JSON'), 'TimeGenerated', coalesce(body('Parse_JSON')?['alert_time'], utcNow())))",
          "headers": { "Log-Type": "SecuritySnares" },
          "path": "/api/logs"
        },
        "runAfter": { "Parse_JSON": ["Succeeded"] }
      }
    },
    "outputs": {},
    "parameters": {
      "$connections": { "type": "Object", "defaultValue": {} }
    }
  },
  "parameters": {
    "$connections": {
      "type": "Object",
      "value": {
        "azureloganalyticsdatacollector": {
          "id": "/subscriptions/<subscription-id>/providers/Microsoft.Web/locations/<region>/managedApis/azureloganalyticsdatacollector",
          "connectionId": "/subscriptions/<subscription-id>/resourceGroups/<resource-group>/providers/Microsoft.Web/connections/azureloganalyticsdatacollector",
          "connectionName": "azureloganalyticsdatacollector",
          "connectionProperties": {}
        }
      }
    }
  }
}

Step 3 — Copy the trigger URL

Save the Logic App, then open the When an HTTP request is received trigger and copy the generated HTTPS POST URL.

Step 4 — Point the SecuritySnares webhook at the Logic App

In SecuritySnares, open webhook configuration and set the endpoint to the Logic App trigger URL. See Webhook Notifications for payload format, signing, and verification details.

Step 5 — Verify ingestion

Trigger a test alert. After a few minutes, the data appears in the SecuritySnares_CL table. Confirm it in Sentinel or Log Analytics with:

SecuritySnares_CL
| sort by TimeGenerated desc
| take 20

Field reference

The custom table mirrors the SecuritySnares webhook payload (see Payload Fields). Because the table is created through the HTTP Data Collector API, Log Analytics appends a type suffix to each column — for example hostname_s, process_sha256_s, action_taken_s (string), and webhook_version_d (number). TimeGenerated is set from the alert's alert_time.

note

Custom log ingestion through the HTTP Data Collector API is supported for existing workspaces. For new deployments, Microsoft recommends the Logs Ingestion API with Data Collection Rules; the Logic App pattern above can be adapted to that API if required.

Agent Modes

SecuritySnares has 3 modes: Alert-Only, Protect and Disabled.

Alert-Only mode will only alert and take no action on the endpoint. New customers are generally onboarded in Alert-Only mode for the first 2-3 weeks to ensure that SecuritySnares will not prevent benign, legitimate business operations, such as backups or software updates.

Protect mode will kill suspicious processes that are attempting to encrypt files. Protect mode is the only way to stop ransomware. It is important to switch a customer to Protect mode as soon as any routine false positives have been detected and entered into the Allow List.

Disabled mode will unload the filesystem driver and service. This mode is ideal when there is a bug on the affected machine and SecuritySnares is preventing proper operation. In Disabled mode, logs can still be collected from the agent, the version is able to be rolled back to a previous version, and updates can occur. For these reasons, it is recommended to use Disabled mode instead of uninstalling.

Mass Move Agents from Alert-Only to Protect

Use the Protection Policy page to move a full customer environment from Alert-Only to Protect.

1. Navigate to Settings & Policies.
2. Select the Protection Policy tab.
3. In Default posture for new & existing hosts, select Protect by default.
4. Review the Live impact preview:
   • Protected now shows agents already in Protect mode.
   • Will change next check-in shows agents that will move from Alert-Only to Protect after the policy is applied.
   • On hold shows agents marked as hold exceptions.
5. Click Apply policy.
6. Review the confirmation dialog, including any highlighted high-impact hosts such as domain controllers.
7. Type PROTECT in the confirmation field.
8. Click Apply to n hosts.

The fleet policy is applied through the portal and agents reconcile on their next check-in. The Agents page displays the current organization policy as Fleet policy: Protect when the organization default is Protect.

Hosts placed on hold are intended for exceptions that should remain in Alert-Only while the rest of the fleet moves to Protect. Use Manage holds on the Protection Policy page, or the Hold and Release -> Protect actions on the Agents page, to manage those exceptions. After applying the policy, verify held hosts and newly protected hosts from the Agents page.

To move the fleet back to Alert-Only, return to Settings & Policies -> Protection Policy, select Alert-only by default, click Apply policy, and complete the same confirmation step.

To have an agent enter the Disabled State, click the Agent Killswitch option within the ellipsis (you must have MFA configured first).

Agent Updates

You can start agent updates from either the Dashboard or the Agents page:

1. From Dashboard → Agent versions, click Update agents to review endpoints that are behind.
2. Navigate to the Agents page.
3. In the top right, click Manage Agent Versions.
4. Click Update for the target release.

Should an agent version rollback be needed, follow the same steps but select Rollback instead of Update.

Setting up MFA

Please navigate to your user profile, then MFA. Ensure the selector is to the right to be turned on.

Single Sign-On (SSO)

SecuritySnares supports Single Sign-On (SSO) through an external Identity Provider (IdP), allowing users to sign in with their existing corporate credentials. Supported providers are Microsoft Entra ID (Azure AD), Google, and Okta. SSO is configured per organization at Settings & Policies → Single Sign On.

This section walks through configuring Microsoft Entra ID (Azure AD).

How SecuritySnares SSO works

SecuritySnares uses the OpenID Connect (OIDC) authorization-code flow with PKCE. When a user signs in with an email address matching your configured Email Domain, SecuritySnares redirects them to your IdP to authenticate, then exchanges the returned authorization code for tokens to establish the session.

note

SecuritySnares redeems the authorization code using PKCE and does not send a client secret during the token exchange. The application must therefore be registered in Entra as a public client (see Step 2). Registering the redirect URI under the Web or Single-page application platform will cause sign-in to fail.

Before you begin

You will need:

• Administrator access to the Microsoft Entra admin center (https://entra.microsoft.com)
• Permission to register applications and create client secrets in your tenant
• Your SecuritySnares portal callback URL: https://portal.securitysnares.com/login

Step 1 — Register an application in Entra

1. Sign in to the Microsoft Entra admin center and go to Entra ID → App registrations → New registration.
2. Enter a Name (e.g., SecuritySnares SSO).
3. Under Supported account types, choose Accounts in this organizational directory only (single tenant) unless you need to allow users from other tenants.
4. Leave Redirect URI blank and click Register.
5. On the app Overview page, copy the Application (client) ID and Directory (tenant) ID — you will need both later.

Step 2 — Add the redirect URI (public client)

1. In the app, open Authentication → Add a platform.

2. Select Mobile and desktop applications.

   warning

   Choose Mobile and desktop applications, not Web or Single-page application. SecuritySnares uses PKCE with no client secret at the token endpoint, and only the public-client platform permits this. Using the Web platform results in error AADSTS7000218 at sign-in.

3. In the Custom redirect URIs field, enter your callback URL exactly, then click Configure:

   https://portal.securitysnares.com/login

note

The redirect URI must match the callback exactly, including the /login path. If you access SecuritySnares at more than one host, register each host's /login URL.

Step 3 — Grant OIDC permissions

1. Open API permissions → Add a permission → Microsoft Graph → Delegated permissions.
2. Add openid, profile, and email.
3. (Optional) Click Grant admin consent for [your tenant] to suppress the per-user consent prompt on first sign-in.

Step 4 — Create a client secret

1. Open Certificates & secrets → Client secrets → New client secret.
2. Add a description and expiry, then click Add.
3. Copy the secret Value immediately — Entra displays it only once.

warning

Store the secret value securely. After you leave the page it is permanently masked, and a lost secret must be replaced with a new one. Set a reminder to rotate the secret before it expires.

Step 5 — Configure SSO in SecuritySnares

1. In the SecuritySnares portal, go to Settings & Policies → Single Sign On → Configure Identity Provider.

2. Complete the form:

   Field	Value
   Name	A label for this provider, e.g., Azure
   Identity Provider Service	AzureAD
   Email Domain	Your organization's email domain (e.g., yourcompany.com). Users whose email matches this domain are routed to Entra. It must be a verified domain with real users in your Entra tenant.
   Authorization Server Host URL	https://login.microsoftonline.com/<tenant-id>/v2.0 (substitute your Directory/tenant ID)
   Client ID	The Application (client) ID from Step 1
   Client Secret	The secret Value from Step 4
   PKCE	Enabled (toggle on)

3. With the Authorization Server Host URL set and PKCE enabled, the Authorization Endpoint, Token Endpoint, and JWKS URI fields populate automatically. Leave them as filled.

4. Click Submit.

Step 6 — Test sign-in

1. Sign out of SecuritySnares, or use a private browser window.
2. Begin sign-in with a user whose email matches the configured Email Domain.
3. You should be redirected to the Microsoft sign-in page and, after authenticating, returned to the SecuritySnares portal signed in.

tip

Test with one account before rolling out. Confirm the user's email domain matches a verified domain in your Entra tenant and that the account exists there.

Reference: Entra OIDC endpoints

For tenant <tenant-id>:

Purpose	URL
Authority / Issuer	https://login.microsoftonline.com/<tenant-id>/v2.0
Authorization	https://login.microsoftonline.com/<tenant-id>/oauth2/v2.0/authorize
Token	https://login.microsoftonline.com/<tenant-id>/oauth2/v2.0/token
JWKS	https://login.microsoftonline.com/<tenant-id>/discovery/v2.0/keys

SSO Troubleshooting

AADSTS50011: The redirect URI ... does not match The callback URL sent by SecuritySnares is not registered on the app. Add the exact URL — including the /login path — under Authentication → Mobile and desktop applications. The path must match exactly; the loopback port-flexibility rule applies only to http://localhost.

AADSTS7000218: The request body must contain ... 'client_secret' The redirect URI is registered under the Web (confidential) platform, which forces Entra to require a secret, but SecuritySnares uses PKCE without one. Remove the redirect URI from the Web platform and re-add it under Mobile and desktop applications.

Redirected to Microsoft, but sign-in fails for the user The user's email domain may not be a verified domain in your Entra tenant, or the user account may not exist there. Verify the domain under Entra ID → Custom domain names and confirm the user account.

First sign-in shows a consent prompt Expected if admin consent was not granted. Either approve the prompt or grant tenant-wide admin consent under API permissions (Step 3).

Create Organization (Adding Customers)

Starting on the Organizations page, click on the Add Organization button.

This will create an organization that is managed by the currently logged in user's organization. For instance, if a user logged in as analyst@AcmeMSSP.com, then Acme MSSP would be the organization responsible for managing the newly created organization's SecuritySnares alerts and deployment.

Fill in the Organization's name, and the information of the first point-of-contact for the client organization.

Interpreter Detection and Script Policy

Execution Scripts

Script Encryption Policy defines how scripting interpreters are handled by the SecuritySnares agent when a script attempts to encrypt data.

Script Policies (Customer‑managed)

Script Policies control if Scripting Interpreters are allowed to encrypt data within your organization.

• Location: Settings & Policies → Script Encryption Policy
• What you configure:
  • Execution Script: choose from the predefined scripts
  • When a scripting interpreter tries to encrypt a file: Allow, Deny, or Alert
  • Rule Type: Agent, Host Group, or Organization

Permissions:

• Administrators: can add, edit, and delete Script Policies
• Standard users: read‑only visibility of Script Policies

Rule Types:

• Agent: applies the policy to a single host (select the specific agent)
• Host Group: applies the policy to a defined group of hosts (host groups are created at https://portal.securitysnares.com/agents.)
• Organization: applies the policy to all agents in the organization

Notes: Use Allow when the interpreter is trusted and required to encrypt data, Deny to block execution, and Alert to surface events without blocking while you evaluate impact.

SMB Protection

SMB Protection prevents ransomware from encrypting files on protected SMB file shares. When a SecuritySnares agent is installed on an SMB server, it monitors incoming write operations and coordinates with SecuritySnares agents on SMB clients to verify that processes writing encrypted data are trusted.

How It Works

• Unprotected SMB clients (no SecuritySnares agent installed) can write unencrypted files to a protected SMB server, but cannot write encrypted files. This prevents unmanaged machines from depositing ransomware-encrypted data onto protected shares.

note

SecuritySnares errs on the side of caution when detecting encryption. In some cases, highly compressed files may be identified as encrypted and the agent will block the transfer. Installing the SecuritySnares agent on SMB clients eliminates these false positives.

• Protected SMB clients (SecuritySnares agent installed) can write to protected SMB servers normally. The two SecuritySnares agents communicate over port 55999/UDP to verify that the process encrypting files on the client is a trusted process.

Network Requirements

SMB Protection requires UDP port 55999 to be open between SMB clients and SMB servers that both have the SecuritySnares agent installed. If port 55999/UDP is blocked, protected SMB clients will be unable to write encrypted data to protected SMB servers.

Firewall Configuration:

Ensure bidirectional UDP traffic on port 55999 is permitted between all endpoints running the SecuritySnares agent that participate in SMB file sharing.

Direction	Port	Protocol	Purpose
Client ↔ Server	55999	UDP	Agent-to-agent trust verification

Deployment Considerations

• Install the SecuritySnares agent on both the SMB server and all SMB clients that need to write encrypted data to protected shares.
• Unmanaged clients can still read files and write unencrypted files to protected SMB servers.
• No additional configuration is required beyond installing the agent and ensuring port 55999/UDP is open.

Webhook Notifications

Webhook notifications allow you to receive real-time alerts from SecuritySnares to your own systems, enabling integration with SIEM platforms, custom applications, and automated security workflows.

Webhook Configuration

Webhooks are configured at the organization level. To configure webhooks:

1. Navigate to Settings & Policies → Notifications
2. Click Add Webhook to create a new webhook endpoint
3. Configure the following:
   • Webhook URL: The HTTPS endpoint that will receive webhook notifications
   • Secret (optional): A shared secret for HMAC signature verification
   • Status: Enable or disable the webhook (toggle switch shows "Activated" or "Deactivated")

You can configure multiple webhooks per organization, and all active webhooks will receive notifications when alerts are detected.

Receiving Webhook Requests

When a SecuritySnares agent detects a suspicious process and generates an alert, the system automatically sends HTTP POST requests to all enabled webhook endpoints configured for your organization.

Request Format

• Method: POST
• Content-Type: application/json
• SecuritySnares-Signature: HMAC-SHA256 signature of the request body (if secret is configured)

The SecuritySnares-Signature header contains a hexadecimal HMAC-SHA256 hash of the request body, computed using the secret you configured for the webhook.

Example Payload

{
  "entity_id": "9bb16cd604ae4a64bf8c862d9997711c",
  "organization_name": "Acme Company",
  "webhook_version": 1,
  "alert_id": "21b1968c7e8f477cab44b3aa3bd2d4ad",
  "hostname": "WIN-SERVER01",
  "process_name": "suspicous.exe",
  "process_id": "9032",
  "process_file_path": "C:\\Users\\Administrator\\Desktop\\suspicous.exe",
  "process_md5": "d41d8cd98f00b204e9800998ecf8427e",
  "process_sha256": "467014615a5255aca450ae88100dd2caf887da87657f00e3c2171ec44a685aec",
  "parent_process_id": "3264",
  "parent_process_file_path": "C:\\Windows\\System32\\cmd.exe",
  "parent_process_md5": "2b40c98ed0f7a1d3b091a3e8353132dc",
  "parent_process_sha256": "badf4752413cb0cbdc03fb95820ca167f0cdc63b597ccdb5ef43111180e088b0",
  "attempted_file_encryption": "C:\\Users\\smith\\Documents\\tmp\\Company_Financials.enc",
  "ip_address": "192.168.1.100",
  "mac_address": "00:11:22:33:44:55",
  "action_taken": "alert",
  "alert_time": "2026-03-24T18:00:44Z",
  "ai_threat_analysis": "Test AI analysis summary"
}

Payload Fields

• entity_id: Unique identifier for the organization
• organization_name: Name of the organization the alert belongs to
• webhook_version: Version of the webhook payload format
• alert_id: Unique identifier for the alert
• hostname: The hostname of the endpoint where the alert was detected
• process_name: Name of the suspicious process (e.g., suspicous.exe)
• process_id: Process ID (PID) of the suspicious process
• process_file_path: Full file path of the suspicious process
• process_md5: MD5 hash of the process executable
• process_sha256: SHA-256 hash of the process executable
• parent_process_id: Process ID (PID) of the parent process
• parent_process_file_path: Full file path of the parent process
• parent_process_md5: MD5 hash of the parent process executable
• parent_process_sha256: SHA-256 hash of the parent process executable
• attempted_file_encryption: File path of the file the process attempted to encrypt
• ip_address: IP address of the endpoint
• mac_address: MAC address of the endpoint's network interface
• action_taken: Action taken by SecuritySnares (e.g., "alert", "killed")
• alert_time: ISO 8601 timestamp of when the alert was detected
• ai_threat_analysis: AI-generated summary of the threat analysis

Verifying Webhook Requests

To ensure webhook requests are authentic and have not been tampered with, always verify the HMAC signature when a secret is configured.

HMAC Signature Verification

The signature is computed as:

HMAC-SHA256(secret, request_body)

The resulting hash is included in the SecuritySnares-Signature header as a hexadecimal string.

Example Verification Code (Python)

import hmac
import hashlib
from flask import Flask, request

app = Flask(__name__)

WEBHOOK_SECRET = 'your_webhook_secret'  # Configure this to match your webhook secret

@app.route('/webhook', methods=['POST'])
def webhook():
    # Get the signature from headers
    provided_sig = request.headers.get('SecuritySnares-Signature', '')
    
    # Get the raw request body
    raw_body = request.get_data(cache=False, as_text=False)
    
    # Compute expected signature
    expected_sig = hmac.new(
        WEBHOOK_SECRET.encode('utf-8'),
        raw_body,
        hashlib.sha256
    ).hexdigest()
    
    # Verify signature using constant-time comparison
    if not hmac.compare_digest(provided_sig, expected_sig):
        return {'error': 'Invalid signature'}, 401
    
    # Parse and process the alert payload
    payload = request.get_json()
    print(f"Alert received for {payload['hostname']}: {payload['process_name']}")
    
    # Process the alert...
    
    return {'success': True}, 200

Example Verification Code (Node.js/Express)

const express = require('express');
const crypto = require('crypto');
const app = express();

const WEBHOOK_SECRET = 'your_webhook_secret';  // Configure this to match your webhook secret

app.use(express.raw({ type: 'application/json' }));

app.post('/webhook', (req, res) => {
  // Get the signature from headers
  const providedSig = req.headers['securitysnares-signature'] || '';
  
  // Compute expected signature
  const expectedSig = crypto
    .createHmac('sha256', WEBHOOK_SECRET)
    .update(req.body)
    .digest('hex');
  
  // Verify signature using constant-time comparison
  if (providedSig !== expectedSig) {
    return res.status(401).json({ error: 'Invalid signature' });
  }
  
  // Parse and process the alert payload
  const payload = JSON.parse(req.body.toString());
  console.log(`Alert received for ${payload.hostname}: ${payload.process_name}`);
  
  // Process the alert...
  
  res.json({ success: true });
});

Retry Logic and Delivery Status

SecuritySnares implements automatic retry logic for failed webhook deliveries:

• Initial Delivery: When an alert is detected, the system immediately attempts to deliver the webhook
• Retry Attempts: If delivery fails, the system will retry up to 3 times.
• Final Status: After 3 failed retry attempts, the webhook is marked as failed

Response Codes

Your webhook endpoint should return:

• 2xx status codes (200-299): Successfully received and processed
• Non-2xx status codes: Delivery failure - will trigger retry logic

Monitoring Webhook Delivery

You can monitor webhook delivery status in the Audit Trail page:

• Filter by Webhook Delivery action type
• View delivery status:
  • Delivered: Successfully sent
  • Retry: Currently being retried
  • Failed: Failed after all retry attempts
• Each entry shows the webhook URL, attempt number, and response code (for failures)

Smart Alert Deduplication

To keep your webhook integrations clean and actionable, SecuritySnares includes built-in smart alert deduplication. When multiple alerts are generated for the same hostname and process name combination, SecuritySnares will consolidate them and deliver only one webhook notification per 60-second window.

This ensures your security team and downstream systems receive meaningful, non-redundant alerts — so you can focus on responding to threats rather than filtering through duplicate notifications. Alerts that occur during a deduplication window are still recorded in the SecuritySnares alert page; only the webhook delivery is deduplicated.

Common Failure Modes

Network Connectivity Issues

Solutions:

• Verify the webhook URL is publicly accessible
• Check firewall rules allow inbound connections from SecuritySnares servers
• Verify the endpoint uses HTTPS

Signature Verification Failures

Solutions:

• Verify the secret configured in SecuritySnares matches your verification code
• Ensure you're computing the HMAC signature on the raw request body (not parsed JSON)
• Use constant-time comparison functions (e.g., hmac.compare_digest() in Python) to prevent timing attacks
• Check for encoding issues (secret should be UTF-8 encoded)

Rate Limiting

Solutions:

• SecuritySnares respects rate limiting responses
• If you implement rate limiting, ensure limits are appropriate for your alert volume
• Consider using a webhook proxy or queueing service if you receive high volumes

SSL/TLS Certificate Issues

Solutions:

• Ensure your endpoint uses a valid SSL/TLS certificate
• Certificate should be from a trusted Certificate Authority (CA)
• Self-signed certificates are not supported for security reasons

Service Protection & Uninstalling

To prevent the unwanted removal of the SecuritySnares agent, SecuritySnares has builtin Service Protection capabilities. This prevents end users and/or malicious actors disabling or removing the protection SecuritySnares provides.

Systems Administrators will want to configure their Uninstall Password by navigating to the Settings & Policies -> Uninstall Password page, then selecting Update uninstall password. The new uninstall password will be propagated through to agents in a secure fashion.

Troubleshooting

Common Installation Issues

Agent Not Appearing in Portal

If the agent doesn't appear in the web portal after installation:

1. Verify Network Connectivity

   • Ensure the endpoint can reach *.securitysnares.com on port 443
   • Test connectivity: Test-NetConnection api.securitysnares.com -Port 443
   • Check firewall rules and proxy settings

2. Verify API Configuration

   • Check that the correct API URL and API Key were provided during installation
   • Review settings at: C:\ProgramData\SecuritySnares\settings.json (encrypted)
   • Use RansomSnare.Agent.Service.exe --show-config to display current configuration

3. Check Service Status

   • Open Windows Services and verify "SecuritySnares Service" is running
   • If stopped, attempt to start the service manually
   • Check Event Viewer for service-related errors

4. Review Installation Logs

   • Check C:\ProgramData\SecuritySnares\Logs\ransomsnare.install.bootstrapper.log
   • Review C:\ProgramData\SecuritySnares\Logs\ransomsnare.install.msi.log
   • Look for error messages indicating installation failures

.NET Runtime Issues

If you encounter .NET-related errors:

1. Verify .NET Runtime 6 or later is installed
2. Download and install .NET Runtime from Microsoft
3. Use the self-contained .exe installer which includes .NET

Permission Errors

If you see permission-related errors during installation:

1. Ensure the installer is run with administrator privileges
2. Right-click the installer and select "Run as administrator"
3. Verify the user account has local administrator rights

Driver Installation Failures

If the filesystem driver fails to install:

1. Check that Secure Boot allows third-party drivers (if applicable)
2. Verify no other security software is blocking driver installation
3. Review Windows Event Viewer for driver-related errors
4. Contact SecuritySnares support for driver signing verification

General Troubleshooting Commands

There are some basic commands that can be executed using RansomSnare.Agent.Service.exe:

• --version - just print version and exit
• --api-key - configure api key, value must be in the next argument
• --api-url - configure api url, value must be in the next argument
• --alert-only - configure alert only mode, value must be in the next argument. Accepted values: on|true|1, or off|false|0
• --self-hosted - put the agent into self-hosted mode (no communication to backend), value must be in the next argument. Accepted values: on|true|1, or off|false|0
• --sys-events - write events to system event log, value must be in the next argument. Accepted values: on|true|1, or off|false|0
• --config - store config values passed from command-line to settings.json
• --install - installs and starts the service
• --uninstall - stops and uninstalls the service
• --show-config - display agent config in console

Should there be an issue with an endpoint, such as resource utilization or conflicts with other software, please collect the logs from the endpoint and send them to your SecuritySnares representative.

To do this, navigate to portal.securitysnares.com/agents, click the ellipse (three dots) next to the host, and click Collect Logs.

This issues a command to the agent, and within a few minutes, the command will be received by the agent. The agent will then collect the logs and post a zip file to the web application. A red dot will appear, indicating the logs are ready.

Click the ellipsis button again, and click Agent Logs. You may then download the latest logs.

To troubleshoot yourself, please refer to the Files and Folders Structure section of this document for information on the various logs.

Should the issue need escalation, please refer to the Support section of this document.

Configuration

Files and Folders Structure

Main app folder

By default, SecuritySnares is installed into C:\Program Files\SecuritySnares on Windows and /etc/securitysnares on Linux. Executable files in this folder:

• RansomSnare.Agent.exe - application engine, .Net console application, can be used for debugging purposes when service is down. Should be started with admin privileges or it will be unable to communicate with the driver. Coordinates work of all components, communicates with the API. You can just print version and exit using --version command-line argument.

• RansomSnare.Agent.Service.exe - windows service, .net application. Supported command-line arguments are:

  • --version - just print version and exit
  • --api-key - configure api key, value must be in the next argument
  • --api-url - configure api url, value must be in the next argument
  • --alert-only - configure alert only mode, value must be in the next argument. Accepted values: on|true|1, or off|false|0
  • --config - store config values passed from command-line to settings.json
    • ex. -config --self-hosted on
  • --install - installs and starts the service
  • --uninstall - stops and uninstalls the service

• RansomSnare.Agent.UI.exe - WPF application, runs in background in user session. It's added to autorun via registry key. Listens to notifications from the service, displays notifications

• RansomSnare.Updater.v2.exe - part of automatic updates system. When a self-update package is downloaded, this app is started under SYSTEM account, stops the service, replaces files and starts the service back

• RansomSnareLib.dll - C++ library, responsible for communication between the driver and the agent. Makes process trust checks, verifies digital signatures. For better performance - answers first to the driver, so it doesn't delay IO. Sends notifications to the agent only when necessary - to fill recovery queue (untrusted file changes), or start recovery process (we already killed suspicious process and want to revert collected changes). Agent then communicates with web portal API and displays UI notifications according to app settings.

Data Folder

By default, SecuritySnares's data folder is C:\ProgramData\SecuritySnares on Windows or /usr/share/SecuritySnares on Linux Files and folders inside:

• Backup - folder with backup files. On start, agent tells the driver the location of backup folder - obviously, without it, driver cannot make backups and it's not working. Write access is prohibited by the driver - cannot change or rename files there, but can create or delete.

• CrashLogs - application crash logs. If the agent service is unexpectedly terminated, on the next start it detects this event, collects all necessary log files and puts it there. When possible, uploads to web console.

• Logs - logs folder

• Temp - folder for temporary files, e.g. self-update packages

• agent.lock - lock file, created when the service starts, removed when it stops

• settings.json - settings file

Logs Folder

By default, the SecuritySnares logs folder is C:\ProgramData\SecuritySnares\Logs on Windows or /usr/share/SecuritySnares/Logs on Linux Files inside:

• ransomsnare.agent.log - Agent-related logs. Errors in the agent itself, information about startup or shutdown sequence.

• ransomsnare.api.log - Detailed information about communication with the web portal. Requests/responses, errors.

• ransomsnare.corelib.log - Logs from lower level, coming from RansomSnareLib.dll. Verbosity can be changed in settings.

• ransomsnare.install.bootstrapper.log - Logs from .exe installer - full install sequence, which dependencies it installs and why.

• ransomsnare.install.msi.log - Verbose logs from agent .msi install. Which files are copied, install actions - installing drivers, services, etc.

• ransomsnare.recovery.log - Logs from recovery queue. Which file changes are queued from which process, and in case if recovery starts - verbose log which files were recovered and which ones were deleted. Also, errors during recovery.

Log File Management:

• Each log file has a maximum size of 10MB
• Old log files are regularly removed automatically to prevent excessive disk usage

Settings.json

The unencrypted version of settings.json resembles the following:

{
  "server_url": "https://ransomsnare-api.securitysnares.com/",
  "updates_url": "https://ransomsnare.securitysnares.com/updates/",
  "poll_url": "/poll",
  "alerts_url": "/alerts",
  "api_key": "111111111111111",
  "instance_id": "22222222222222",
  "last_installed_version": null,
  "polling_interval": 60,
  "lib_log_level": 0,
  "alert_only": false,
  "suspend_only": false,
  "notification_type": "dialog",
  "show_system_tray": false,
  "notification_message": null,
  "report_system_event_log": true,
  "self_hosted": false
}

Fields in the settings file:

• server_url - root url of the web portal server. Used to poll commands, obtain whitelist, report alerts, etc. Populated via API_URL field during agent installation.
• updates_url - root url of the updates server. Can be used to override default updates url
• poll_url - not used at the moment. Absolute or relative (to server_url) url to poll commands from.
• alerts_url - not used at the moment. Absolute or relative (to server_url) url to report alerts to.
• api_key - api key for the customer's tenancy within the web portal. Populated via API_KEY field during agent installation.
• instance_id - auto generated unique host id. This is to identify agent on the web portal
• last_installed_version - filled by the app, used for self-update mechanism
• polling_interval - interval, in seconds, between requesting commands from the web portal.
• lib_log_level - verbosity level of the core library (between the driver and the agent). 0=DEBUG,1=INFO,2=WARN,3=ERR. Larger number = less verbosity
• alert_only - alert only flag (true|false). Can be set using ALERT_ONLY field during agent installation.
• suspend_only - suspend only flag (true|false). If set to true - agent will suspend processes instead of killing
• notification_type (dialog|systray|msgcenter|none) - not fully supported at the moment, and not on all OS types. Type of notifications - popup dialog, system tray, message center, or no notifications.
• show_system_tray (true|false) - if set to true, displays an icon in the system tray.
• notification_message - custom text for notification message
• report_system_event_log (true|false) - if set to true, writes alerts to system event log
• self_hosted (true|false) - if set to true, turns agent to self-hosted mode, when it doesn't communicate to the web portal and doesn't check for updates.

Settings

For Windows, settings.json is usually located at C:\ProgramData\SecuritySnares\

As settings.json is encrypted, if you require to make any configuration changes, open cmd.exe as an Administrator. The following are examples of configuration changes that can be made:

C:\Program Files\SecuritySnares>RansomSnare.Agent.Service.exe -config --alert-only on

C:\Program Files\SecuritySnares>RansomSnare.Agent.Service.exe -config --alert-only off

C:\Program Files\SecuritySnares>RansomSnare.Agent.Service.exe -config --api-url https://api.stage.securitysnares.com/

If you receive the following error, it is because you are not running cmd.exe as administrator:

C:\Program Files\SecuritySnares>RansomSnare.Agent.exe -config --alert-only off
Unhandled exception. System.ArgumentNullException: Path cannot be null. (Parameter 'path')
   at System.IO.Strategies.FileStreamHelpers.ValidateArguments(String path, FileMode mode, FileAccess access, FileShare share, Int32 bufferSize, FileOptions options, Int64 preallocationSize)
   at System.IO.FileStream..ctor(String path, FileMode mode)
   at RansomSnare.Agent.Util.FileEncryptUtil.WriteAllText(String fileName, String text) in C:\Work\Outside\EcorRuge\ransomsnare-agent\src\agent\RansomSnare.Agent\Util\FileEncryptUtil.cs:line 113
   at RansomSnare.Agent.Settings.SettingsFile.Save() in C:\Work\Outside\EcorRuge\ransomsnare-agent\src\agent\RansomSnare.Agent\Settings\SettingsFile.cs:line 160
   at Program.<Main>$(String[] args) in C:\Work\Outside\EcorRuge\ransomsnare-agent\src\agent\RansomSnare.Agent\Program.cs:line 190
   at Program.<Main>(String[] args)

Support

SecuritySnares is available for contact:

By phone

• US: +1 888-326-5761
• Europe: +44 808-812-7289
• Asia Pacific: +61 1800 920 730

By email

• support@securitysnares.com

By Slack

• Ask your SecuritySnares representative for an invite!