IstroSec GRYPHON

See How GRYPHON Works
Product Brief
Request a Demo

Agent-based Advanced Defense and Incident Response toolkit designed to complement EDR/XDR and strengthen a multi-layer resilience strategy.

About GRYPHON

GRYPHON is the first Defense and Incident Response (IR) toolkit - behavioral ransomware and APT attacks protection with an integrated anti-malware engine, kernel-level rule enforcement, autonomous file recovery, and a full IR console in the one agent - developed by IstroSec, trusted European cybersecurity vendor, driving resilience through incident response experiences, innovation and global technology alliances.

Incident response fostering.

A new class of defense tool for teams who must stop ransomware mid-encryption, quarantine the malware that reach disk, recover the files the attack touched, and run the forensic investigation - in the same product.

Behavioral ransomware defense. Integrated anti-malware. Protected file recovery. Full IR built in.

GRYPHON blocks ransomware (including strains no one has catalogued) with a behavioral engine that needs no signatures and no cloud. A separate anti-malware engine adds static analysis and quarantine. When prevention isn’t perfect, protected file storage restore what was touched. The same agent is your IR console afterwards.

When the breach is already in progress, most tools give up. GRYPHON starts there.

The first incident response toolkit designed to deploy inside a compromised environment, stop the attack, quarantine the malware, recover what was damaged, and help you regain control.

Product

For fifteen years, endpoint security split into two camps

EDRs alert and prevent, but when a real incident begins, they hand you off to a ticket, a SIEM, and a team of consultants. Anti-malware scans files, quarantines known bad, and tells you little about behaviors. DFIR tools do the investigation, but they assume you’re already in the breach and offer nothing to stop it.

GRYPHON, the agent-based toolkit, merges all three approaches into one product.

Combines two complementary detection engines - a behavioral Policy engine (kernel-level rule evaluation on live activity) and an integrated Anti-Malware engine (static analysis, quarantine, scheduled and on-demand scans, AMSI-based script inspection). When either engine fires, the same agent opens a Remote Desktop session, a remote PowerShell terminal, a File Manager, and a Process Manager on any endpoint under investigation. It runs forensics scripts on one endpoint or ten thousand, isolates a compromised host with a customizable Isolation Firewall, and deploys third-party tools through its own channel. No handoff. No second console. No third-party vendor.

Built on two decades of experience with market-leading EDR/XDR platforms and real incident-response engagements. Written as a pure C++ service and kernel driver the client is self-contained and can be deployed into environments you don’t fully trust.

Block ransomware. If it breaks through, roll back the damage - powered by Volume Shadow Copies ransomware can’t delete.

Features

Behavioral ransomware defense

No signatures. No cloud. Works on strains nobody has seen yet.

Signature-based anti-malware fails on novel ransomware, and threat-intelligence feeds lag active campaigns by days. GRYPHON’s behavioral ransomware engine is built differently.

The engine evaluates every running process against the operational fingerprint of encryption in progress: mass or suspicious file operations, shadow-copy deletion attempts, Lolbin invocation patterns, suspicious service installation, crypto API usage, registry markers, double-extension file creation, and dozens of other behaviors. It runs on the endpoint. It does not depend on a cloud verdict. Because it recognizes behaviors, it catches strains that have never been catalogued.

Layered on top, GRYPHON enforces a set of ransomware-specific kernel-level protections:

  • VSS/VolumeBackup Protection. The first move of every modern ransomware playbook is deleting Volume Shadow Copies to eliminate recovery. Gryphon blocks that at kernel level.

  • Automatic VSS/VolumeBackup Creation. Daily snapshots, snapshots when suspicious operations are performed, plus snapshot creation when none are present, ensure recovery points exist when needed.

  • Autonomous File Recovery. When an attack is detected, affected files are automatically restored from protected Volume Shadow Copies.

  • Kernel-level anti-tamper. Gryphon Shutdown Hardening, Service Hardening, Uninstall Hardening, and Network Hardening prevent the attacker from taking GRYPHON out first. Shutdown and uninstall require a service token; service process termination is blocked at kernel level. Uninstall attempts are surfaced as separate alert independently of whether they succeed.

When the engine converges on a ransomware verdict, GRYPHON blocks the process, kills it, and (where files were encrypted before the kill) restores them from the protected copy.

Integrated Anti-Malware engine - static analysis, quarantine, and scans

Not necessary to keep buying a separate Anti-Virus (AV). GRYPHON integrates both.

GRYPHON ships with an integrated Anti-Malware engine alongside the behavioral Policy engine. The two engines are complementary: Policy evaluates behavior on live events; Anti-Malware performs static analysis and scan-time detection. Either engine can be the source of an alert - the alert metadata tracks which engine fired.

Capabilities:

  • Static malware analysis using the integrated detection engines, alert types covering file-, process-, and script-level detection.

  • Quarantine. When enabled, detected malware is moved to quarantine instead of simply blocked from opening. Quarantined files retain SHA256 and path metadata for incident review and potential release.

  • Scheduled and on-demand scans. Full or custom scans can be triggered manually from the console or scheduled; scan results track files-scanned count, malware-found count, duration, and links to the resulting detections.

  • Automatic Initial Scan. New endpoints are scanned automatically once the agent is online and the virus database has loaded.

  • Real-time monitoring of network files and removable drives (both are independently configurable; quarantining of files on removable drives is a separate toggle).

  • Archive scanning (ZIP, RAR, etc.) - optional, with an explicit performance-cost note. Archive scanning can be disabled in favor of scanning files on extraction.

  • AMSI script integration. PowerShell and other scripts are scanned through the Windows Antimalware Scan Interface

  • Sample upload for analysis is opt-in, off by default, and explicitly flagged: suspicious executables can optionally be sent to IstroSec’s 3rd party authorized analysis partners. No data leaves the endpoint without the administrator enabling it.

For SME customers, GRYPHON can replace traditional AV solutions - delivering one agent, one console, one licensing model, and integrated incident response capabilities.

Autonomous file recovery - protected rollback, not best-effort backup

Detection alone doesn’t save the business. Recovery does. But recovery only works if the attacker can’t take it out first.

Every ransomware playbook of the last five years opens the same way: delete the Volume Shadow Copies, then encrypt. Organizations with VSS-based rollback find their shadow copies gone when they need them. That’s why most EDRs treat prevention and backup as separate problems and why most ransomware engagements end with a restore from off-host backup, measured in hours or days.

GRYPHON closes this loop on the endpoint:

  • Kernel-level VSS Protection. Shadow Copy deletion is blocked before it completes. vssadmin delete shadows fails; Ransomware’s opening move doesn’t land.

  • Automatic VSS Creation. Daily, and on-demand when no snapshots exist. Recovery points are current when an attack happens.

  • Automatic Ransomware File Recovery. On detection by the behavioral engine or the Anti-Malware engine, affected files are restored from the protected shadow copies - automatically, on-endpoint, without invoking external backup systems.

  • Optional external-drive coverage. VSS creation on USBs and other external drives is available for environments that need it, with explicit performance guidance.

  • Tunable VSS storage. Max VSS Size is configurable from 0–100% of disk (recommended 10%) or set to 0 to let Windows decide.

Instead of “blocked at 3%-restore from backups,” it becomes “blocked at 3%-damage rolled back inline.”

Kernel-level rule enforcement - action before the attack completes its next instruction

Most EDRs collect telemetry in the kernel and evaluate rules in user mode. GRYPHON’s rule engine runs in the driver.

The user-mode evaluation model has a latency window measured in milliseconds on paper, long enough in practice for a process injection to complete, a file encryption loop to start, or a credential-dumping primitive to finish its work. Gryphon’s kernel driver evaluates rules in the same callback as the triggering event. The detection decision and the response action - kill, block, report, add classification, modify variable, run command or anything else - happen before the user-mode operation that triggered them completes.

The rule engine is GRYPHON ’s own language - analyst-readable, designed for real-time evaluation. The language supports:

  • Rich event types. OnProcessPreCreate, OnRegistryValueChange, OnFileCreate, OnFileRename, OnFileSetOwner/Group/DACL, OnImageLoad, OnConnectionEstablished, OnConnectionInfo (with SSL and hostname detection), OnConnectionClosed, OnDnsRequest, OnSocketListen, OnRegistryKeyCreate/Delete/Rename, OnVolumeOpen, OnEvent (ETW), and more.

  • Stateful variables. Per-process and system-wide integer and flag variables, inspectable in condition logic and modifiable from actions.

  • Rich condition logic. Equals, contains, starts/ends with, any-of, regex match, regex contains, group match, group contains - combined with and / or / none operators into arbitrary logical trees.

  • Response actions. Block, print, report, kill, add_classification, modify_variable, run_command.

  • Role- and group-scoped deployment. Rules are scoped to endpoint groups or endpoint roles (Workstation, Server, Domain Controller, Jump Host, Webserver) through the Tags and Targets system. Rules can be imported in Gryphon’s native format or as YARA.

Kernel-level does not mean opaque. Rule definitions are visible, auditable, and editable. The kernel is where they execute not where they’re hidden.

500+ kernel-level rules. The LOLBAS catalogue. Four blocking levels. You pick your paranoia.

Deployment

IT Endpoint infrastructure - Cloud, hybrid and on-prem

Designed to offer protection even in offline mode

GRYPHON is deployed as a lightweight endpoint agent managed from a central console. The same agent and the same protection logic are used across every environment; only the console placement changes between deployment models:

  • Cloud console - GRYPHON-hosted management plane; fastest to stand up, no server infrastructure on the customer side.

  • On-prem console - fully customer-hosted, suitable for air-gapped, regulated, and sovereignty-constrained environments where no external connectivity is permitted.

  • Hybrid - agents in segmented or partially connected networks (typical of OT/ICS) reporting to an on-prem console, with optional upstream aggregation.

Protection is not dependent on console connectivity. Detection, enforcement, anti-malware, and recovery run on the endpoint itself, so an endpoint that is offline, air-gapped, or temporarily disconnected from its console remains protected.

The GRYPHON agent is the enforcement and detection point on every endpoint:

  • Platform coverage - Windows 7 SP1 (fully patched) and Windows Server 2008 R2 through Windows 11 and current Windows Server - every Windows release in between is supported. Windows 7 / 8 / 8.1 run in a limited-support tier, with some features disabled due to Microsoft end-of-life status. This range deliberately covers the legacy and OT footprint that most modern EDRs refuse to install on: HMIs and operator stations, Windows 7 embedded variants on manufacturing lines, certified legacy infrastructure (medical, financial terminals, POS), and intentionally frozen air-gapped systems.

  • Footprint - minimum 2 GB RAM and 2 GB disk.

  • Implementation - native C++ core with .NET 4.0+ for the management components - no exotic runtime dependencies and no components incompatible with locked-down legacy environments.

  • On-endpoint capabilities - detection, kernel-level enforcement, integrated anti-malware, and autonomous recovery, all resident locally. The ransomware targeting OT is the same ransomware targeting IT, so the endpoint defenses are identical across the supported range - a Windows 7 OT station is protected the same way a Windows 11 workstation is.

The Gryphon agent ships as a single Windows Installer package, IstroSetup.msi. Every deployment method below installs the same agent; they differ only in automation. All methods require administrative/elevated privileges, and registration with the console is driven by an installation key (InstallString) generated in the console.:

  • GUI installer.

  • Silent MSI / scripted.

  • SCCM / Intune.

  • GPO (domain-wide)

  • Any other software deployment tool

Legacy and OT-friendly - Windows 7 SP1 through Windows 11

Most modern EDRs drop support for anything older than Windows 10. Gryphon doesn’t.

This matters for:

  • OT and ICS environments where HMIs and operator stations often run legacy Windows and cannot be easily upgraded without production disruption.

  • Industrial control systems and manufacturinglines running Windows 7 embedded variants that modern EDR agents refuse to install on.

  • Regulated legacy infrastructure - medical devices, financial terminals, point-of-sale systems - with certification lifecycles that outlast Microsoft’s support cycles.

  • Air-gapped networks where Windows updates are managed through change control and operating systems are intentionally frozen.

GRYPHON’s on-endpoint detection, kernel-level enforcement, integrated anti-malware, and autonomous recovery work on these systems the same way they work on Windows 11. The ransomware that targets OT environments is the same ransomware that targets everywhere in IT environment else.

FAQ

It shares features with EDRs — kernel-level detection, behavioral rules, kill/block/report actions. The shape is different. EDRs are prevention-and-alerting products that hand off to humans and other tools once an incident starts. GRYPHON 's architecture is shaped around the incident itself: the IR console, the remote shell, the file manager, the integrated anti-malware, the forensics runbooks, the customizable Isolation Firewall, the autonomous file recovery, the deploy-into-a-breach use case. We call the category the Incident Response toolkit.
GRYPHON's recovery subsystem uses Windows Volume Shadow Copies but with a critical difference from the standard model: In Windows GRYPHON protects VSS from deletion at kernel level (so the standard ransomware opening move, vssadmin delete shadows, is blocked and surfaced as a VssTamperingDetected alert), creates VSS snapshots automatically on a daily schedule, and restores affected files from the protected snapshots when ransomware is detected. The chain is: *protect recovery infrastructure → create recovery points → detect attack → restore*. It requires no external backup and runs entirely on endpoint.
For most customers it could be suitable replacement. GRYPHON is delivered with an integrated Anti-Malware engine — static analysis, quarantine, scheduled and on-demand scans, AMSI script scanning, network- and removable-drive real-time monitoring. Alongside the behavioral Policy engine, the two cover the space traditionally split between AV and EDR. GRYPHON also forwards Windows Defender detections into its own console if you continue running Defender.
GRYPHON's kernel driver evaluates detection rules inside kernel callbacks, in the same execution path as the triggering event. Response actions - block, kill, report - happen before the user-mode operation that triggered them completes. This is architecturally different from EDRs that do kernel telemetry with user-mode rule evaluation - a design that creates race windows real attacker’s exploit.
Yes - as one detection source among several. The AIDetection alert type surfaces detections from GRYPHON's AI-assisted detection engine, alongside the Policy engine (behavioural rules), the Anti-Malware engine (static analysis), and IOC matching (IocMatched). We don't position GRYPHON as "AI-first" because most of the heavy lifting is done by deterministic, auditable kernel-level rules and engines that do not depend on model inference. AI is a component; it is not the whole story.
Twenty-seven, covering every detection and response path: BlocklistEntryMatched, IocMatched, LolbinUsed, PersistencyCreated, BehavioralRuleMatched, ThreadInjected, ADSUsed, RansomwareDetected, ProcessHerpaderpingDetected, ProcessDoubleExtensionDetected, ProcessDopplegangingDetected, ProcessHollowingDetected, ProcessGhostingDetected, MaliciousFileDetected, MaliciousProcessDetected, MaliciousScriptDetected, MinidumpCreated, ProcessTamperingDetected, YaraRuleMatched, FirewallRuleMatched, VssTamperingDetected, WindowsDefenderStatusChanged, WindowsDefenderConfigChanged, WindowsDefenderDetection, AgentUninstalled, AgentUninstallAttempted, FilePolicyViolated, AIDetection.
Yes. Network Isolation activates GRYPHON's Isolation Firewall - a separate rule set from the Standard Firewall, defaulting to BlockAll. You edit the Isolation Firewall to allow specific services the isolated endpoint still needs (DNS, patch infrastructure, your SIEM, specific IR tooling). GRYPHON itself always retains management access. This lets you contain a host while preserving whatever connectivity your investigation requires.
The behavioral engine is designed to detect unseen strains with high confidence, independent of signatures and without cloud dependency. The integrated Anti-Malware engine adds signature- and heuristic-based coverage for known families. Independent lab results are available under evaluation agreements. We don't publish a single "percentage effectiveness" number - real-world ransomware detection varies by strain, environment, telemetry policy, and deployment posture, and any vendor publishing a single percentage is selling marketing, not data.
No. Both detection engines, kernel-level rule evaluation, VSS protection, autonomous file recovery, FIM, anti-malware scanning, and process reputation (based on environment prevalence, not cloud lookup) all run on the endpoint. GRYPHON can be deployed fully on-premise, including in air-gapped environments. The agent is pure C++ and self-contained. Optional sample upload to IstroSec's 3rd party authorized analysis partners is off by default.
Yes — and the product was designed for it – to strengthen containment and eradication procedures. The C++ client is self-contained, requires no baseline period, runs safely alongside tools the attacker may have already compromised, and begins protecting on first boot. The "new" group provides zero-trust onboarding that prevents rogue agent deployment from being automatically trusted. Files damaged after GRYPHON's arrival are automatically recoverable.
Windows 7 SP1 (up-to-date, limited support acknowledged) and Windows Server 2008 R2 and later. 64-bit only. Minimum 2 GB RAM, 2 GB disk, .NET Framework 4.0+. GRYPHON's legacy-OS support is deliberate - OT, ICS, regulated medical and financial terminals, and air-gapped infrastructure all frequently run Windows versions that modern EDR products often refuse to install on.
GPO with MST transforms. Generate an .mst file with Microsoft's Orca editor, embedding the installation key (and proxy settings if applicable), attach to a Group Policy software-installation package, and deploy. Full instructions ship with the product documentation. For non-domain environments, SCCM, Intune, and standalone MSI deployment are all supported.
Yes. The Policy engine uses GRYPHON's own analyst-readable rule language. YARA rules can be imported directly. Rules are scoped to endpoint groups or roles through the Tags and Targets system and compile into kernel-safe form at load time. Severity, MITRE ATT&CK mapping, and description fields are first-class.
GRYPHON is suitable to replace existing AV for most customers through its integrated Anti-Malware engine or run alongside it - Windows Defender integration is first-class. For third-party AV or EDR, add C:\Program Files\IstroSec GRYPHON\* to their exclusion list to prevent interference.
Yes. Multi-tenant architecture with site-level data isolation, per-tenant licensing, and per-tenant user management are built in. Console authentication is certificate + 2FA; API key management is per-tenant with configurable expiration and revocation; SIEM export is per-tenant via both bearer-token pull API and push-based SYSLOG forwarders.

Incident Response

Incident Response Console. Single command hub for any ongoing incident: endpoint state, process tree, network context, user context, file changes, alerts from both engines, all in one view. Alert metadata includes the Engine (Policy / Anti Malware / AI Detection), the Actions Taken (Detected only / Killed / Blocked), the Account name, the Assessed Threat Level, Status, and operator comments.

Kernel-level detection and response. Rule evaluation and enforcement happen inside the kernel driver, in the same callback as the triggering event.

Integrated anti-malware. Static analysis, quarantine, scheduled scans, on-demand scans, AMSI script scanning - in the same agent.

Protected autonomous file recovery. Kernel-level VSS/VolumeBackup Protection + Automatic VSS/Volume Backup Creation + Ransomware File Recovery, chained together to roll back encryption damage.

Remote Desktop and remote PowerShell terminal. Investigate a compromised endpoint as the attacker sees it. Visual and text consoles, both protected, both auditable.

Remote File Manager. Pull files off the endpoint. Drop investigative tools onto it. Examine artefacts in place. All through the same agent that detected the attack.

Remote Process Manager. Live listing of active processes on any managed endpoint, with PIDs, command-line arguments, process reputation, and executable hashes.

Custom response scripting. Built-in PowerShell and cmd script editor that produces structured, parsable output - one endpoint or ten thousand. Scripts are organised through Script Tags.

Predefined Actions. Disconnect User, Full Disk Scan, Restart Computer, Malware Scan, and other system-level operations implemented directly in the core product.

Customisable endpoint isolation. Network Isolation activates an Isolation Firewall with a default BlockAll rule - but the Isolation Firewall is separately editable, so you can allow specific services (DNS, patch servers, your SIEM destination) even while an endpoint is isolated. Gryphon itself retains management access throughout.

Third-party tool deployment. Push Sysinternals, KAPE, custom binaries, or any supporting tool to the endpoint through the same agent you’re already running.

Temporary IR accounts. Create short-lived user accounts on endpoints for incident-response activities - no need to compromise the regular identity infrastructure during an incident.

** Containment & Eradication in active breach deployments: Key differentiators **

Most security tools assume they’re being installed into a clean environment. GRYPHON doesn’t.

When infrastructure is already compromised - when the attacker is moving laterally, when ransomware has begun encrypting, when existing tools have been blinded or subverted - you don’t have time for a staged rollout and a two-week baseline period.

GRYPHON was architected for exactly this scenario:

  • Pure C++ client. Self-contained service and kernel driver. Runs on endpoints you don’t fully trust.

  • Kernel-level detection on first boot. No baseline period, no learning window. Both engines behavioural Policy and Anti-Malware begin protecting immediately.

  • Automatic Initial Scan. First-run malware scan on every new endpoint, started once the virus database is loaded.

  • Zero-trust onboarding via the “new” group. Fresh agents land in a quarantine-like default group with minimal policy and no console control surface - only the most basic endpoint data is gathered. Moving an endpoint out of the “new” group is an explicit operator decision: “yes, this endpoint is mine, and I want it in active monitoring.” This protects against rogue agent deployment from a compromised environment.

  • No cloud dependency. Detection, response, quarantine, and recovery all run on the endpoint. Air-gapped deployments are supported.

  • Co-exists with compromised tools. Deploys alongside tools the attacker may have already subverted.

  • File recovery starts at deployment. VSS/volume Backup Protection and Automatic VSS/Volume Backup Creation begin on install - files damaged after Gryphon’s arrival are recoverable.

  • Universal deployment. Mature enterprise deployment via any standard tools.

This is the use case Gryphon was built for: you walk into a breach already in progress, you deploy Gryphon, you regain control.

Advanced Defense

Detection coverage - LOLBin defense and process manipulation.

1000+ real-time detection rules with analyst-extensible coverage, across two complementary engines.

The Policy engine evaluates behavior in kernel space; the Anti-Malware engine performs static analysis and scan-time detection. Alerts from either source surface in the same console with explicit Engine attribution.

LOLBin (Living-off-the-Land Binaries) defense - four blocking levels - certutil, bitsadmin, mshta, rundll32, regsvr32, wmic, the PowerShell family, cscript/wscript, msiexec, and the rest of the LOLBAS catalogue - are legitimate Windows tools that attackers repurpose to evade signature-based defences. Gryphon ships four LOLBIN Block Levels:

  • Never block - LOLBIN blocking disabled.

  • Ransomware (recommended) - blocks only the LOLBINs most heavily abused in ransomware kill chains.

  • Normal - standard coverage across common abuse patterns.

  • Paranoid - maximum coverage for high-risk environments.

Administrators pick the level that matches their risk posture; detection rules reason about context (parent process, command-line arguments, network behavior, side effects), not just the binary name. LOLBIN use generates LolbinUsed alerts.

Process manipulation - named technique coverage, each with its own alert type

Advanced Process Image Protection detects and blocks specific process-hiding techniques by name, with a dedicated alert type for each such as:

  • Process Hollowing → ProcessHollowingDetected - replacing an image before thread creation.

  • Process Doppelgänging → ProcessDopplegangingDetected - creating within a write transaction and reverting.

  • Process Herpaderping → ProcessHerpaderpingDetected - modifying after section creation.

  • Process Ghosting → ProcessGhostingDetected - deleting after section creation.

  • Double-extension spoofing → ProcessDoubleExtensionDetected - executable with misleading double extension.

Plus broader protections: Remote DLL Injection (ThreadInjected), LSASS Minidump Detection (severity automatically raised when lsass.exe is dumped outside Windows Error Reporting, via MinidumpCreated), and LSASS Protection (access to the lsass service is revoked at kernel level).

Remote access coverage, when lateral movement and remote-execution attack surfaces are covered by independent toggles:

  • Local Admin Share Protection - blocks remote access to admin shares.

  • Local Drive Share Protection - blocks remote access to local drives.

  • Remote Execute Protection - blocks execution of binaries from remote paths.

  • Remote Loopback Execute Protection - blocks execution from loopback devices

  • Cloud Execute Protection - blocks execution of binaries from synced cloud locations (OneDrive, etc.).

Each layer can be independently enabled and independently logged.

Exfiltration Protection covers sensitive-data network-exfiltration paths through firewall coordination and rule-level enforcement.

Lateral Movement Protection targets network-traversal attack patterns. Both are group-policy toggles.

Two detection engines. One console. Zero cloud dependency.

Zero Trust

File Integrity Monitoring and Zero Trust posture

Real-time change auditing on what matters - on the same event stream that feeds detection.

File Integrity Monitoring runs as part of GRYPHON’s Zero Trust module, at kernel level, through the same event pipeline as the detection engine. Every create, modify, rename, ACL change, ownership change, and attribute change on a monitored path generates a tamper-resistant record.

Why it’s part of the toolkit, not a separate tool:

  • Compliance evidence. PCI DSS 11.5, NIST SP 800-53 SI-7, CIS Control 3.14 - FIM evidence without a second agent, second vendor, or second audit trail.

  • Detection. Unauthorised binary replacement, web-shell deployment, configuration drift, and registry-based persistence installation - any “paths that shouldn’t change but did” event.

  • Incident response. “What changed during the incident window?” becomes a queryable answer in the IR console, pivotable to the process tree that made each change.

  • Insider threat. Admin-level changes captured independently of the admin’s own audit trail.

FIM is a first-class rule engine citizen. An integrity violation on a protected path can trigger any GRYPHON action - report, kill, block, isolate, run a response script, or invoke autonomous file recovery to restore the changed file.

The Zero Trust module also includes GRYPHON’s own kernel-level firewall, operating independently of (and alongside) Windows Defender Firewall.

Integrations

GRYPHON fits into the stack you already run.

  • SIEM REST API (pull). Bearer-token authenticated endpoint for tenant-level alert retrieval, with alert filtering by type, time range, and cursor-based pagination. 27 alert types covering the full detection surface (see FAQ).

  • SIEM forwarders (push). Standard SYSLOG-style log forwarder configurable from the Organization console - for real-time, push-based SIEM integration alongside the pull API.

YARA rule import. Native YARA support in the detection rule system.

  • AMSI integration. Script scanning through the Windows Antimalware Scan Interface.

  • Custom Actions. Third-party tools - Sysinternals, KAPE, custom binaries - deployable through GRYPHON ’s agent channel.

  • Certificate + 2FA console authentication. Every console user authenticates with a personal PKI certificate (user.pfx) plus a TOTP 2FA token. Credentials, certificates, and login tokens are rotatable from the admin interface.

  • Multi-tenant architecture. Site-level tenancy with per-tenant licensing and per-tenant data isolation. Built for MSSPs and multi-business-unit enterprises from day one.

  • API keys. Programmatic integration via bearer-token API keys with configurable expiration (8 hours to 365 days), revocation, and rotation.

GRYPHON is designed to run alongside the endpoint tools organization already own - not to force a rip-and-replace.

Most organizations run incumbent EDR or anti-malware stack that survived the last procurement cycle and will survive the next one. GRYPHON’s default deployment model is cooperative: it runs on the same endpoint as existing tools, adds the capabilities they don’t have (kernel-level behavioral detection, autonomous file recovery, integrated IR console, FIM, vulnerability management, custom firewall), and stays out of their way for the capabilities they do have.

GRYPHON has been deployed alongside Microsoft Defender for Endpoint, CrowdStrike Falcon, SentinelOne Singularity, Sophos Intercept X, VMware Carbon Black Cloud, Palo Alto Cortex XDR, Trellix Endpoint Security (formerly McAfee MVISION), Bitdefender GravityZone, ESET PROTECT, FortiEDR, Trend Micro Vision One, Kaspersky Endpoint Security, Cybereason, WithSecure (F-Secure), and Harmony Endpoint (Check Point).

For environments running EDR, GRYPHON is a detection multiplier and, if necessary, can replace EDR’s AV role through its integrated Anti-Malware engine. For environments where EDR is disabled or tampered with, GRYPHON surfaces that fact before it’s exploited.

Assets & Network

You can’t defend what you don’t know is there.

Asset Management is GRYPHON’s inventory and vulnerability surface with five submodules

Programs. Global and per-endpoint listing of installed applications. Vendor, version, type (EXE/MSI/APPX), and - where present - mapped CVE entries.

Vulnerabilities. Every vulnerability observed across the managed estate: CVSS score, EQSS score, CVE identifier, publication date, last observation date, automatic-exploitability flag, exploited-in-the-wild flag, technical-impact classification, and a custom GRYPHON Severity score derived from exploitability and prevalence. Pivot from any vulnerability to the affected endpoints and programs.

Pending Updates. Outstanding Microsoft and 3rd party updates across the estate with list of affected endpoints.

Persistence. Every persistence mechanism observed across endpoints

Process Reputation. SHA256, SHA1, MD5 hashes, signing status, uniqueness in the environment, a reputation score derived from version / signature / issuer / environment-prevalence, and threat intelligence links for every distinct executable observed across the estate.

This is the work that makes everything else possible - and most security teams do it with a separate vulnerability scanner, a separate software-inventory tool, a separate persistence-detection script pack. GRYPHON consolidates it.

Custom firewall - process-aware network control, Standard and Isolation policies

Most firewalls see packets. GRYPHON’s firewall sees processes, users, and command lines and maintains multiple distinct policies.

GRYPHON includes its own kernel-level firewall, independent of Windows Defender Firewall or Iptables/nftables, with two separate policy sets:

  • Standard Firewall - the regular operating policy for endpoints in normal state.

  • Isolation Firewall - activates automatically when the endpoint is placed into Network Isolation. Defaults to a BlockAll rule, but is separately editable: you can allow specific services (DNS, patch servers, SIEM destinations, your IR console) even while the endpoint is otherwise isolated. GRYPHON itself retains management access throughout ans and allow creation of network islands.

What GRYPHON’s firewall adds over packet-level rules in both policies:

Process-aware matching. Rules match on Process Name, Command Line, Process Path, and User SID not just IP and port.

Signed-binary awareness. Rules can require or exclude signed binaries.

Role-based and group-based targeting. Rules apply to endpoint roles (Admin Workstation, Terminal Server, Server, Workstation, etc.) and can be included or excluded at the group level, rather than requiring per-host configuration.

Decisions. Allow, Block, Alert only - with directional matching (Inbound, Outbound, Any) and Is Domain Network conditioning.

For defenders dealing with lateral movement or active incident response, the process-level visibility is operationally decisive: “block anything except a signed Microsoft binary from making outbound connections on port 445” is one rule, not a SIEM hunt.

Contact Us

Cernysevskeho 10, 851 01 Bratislava, Slovakia
gryphon@istrosec.com
sales@istrosec.com