Bitdefender GravityZone PHASR

Why do you need dynamic endpoint hardening?

An attacker does not have to bring their own malware - PowerShell, WMI and PsExec are already on every endpoint. Living-off-the-land techniques use legitimate system tools for lateral movement, privilege escalation and ransomware payload deployment. For an EDR this is a hard case: the tool itself is legitimate, and telling malicious use from normal use takes time that does not exist during an attack.

GravityZone PHASR (Proactive Hardening and Attack Surface Reduction) approaches the problem from the other side: instead of detecting abuse after the fact, it restricts each tool to the actions a given user actually performs at work. The attack path disappears before anyone tries to take it - regardless of which EDR the organization runs.

How does it work?

A behavioural profile per user and endpoint

Using AI algorithms, PHASR builds a separate profile for every user-endpoint pair: which tools this person uses, which actions they perform, what they never touch. An administrator has one profile for work on their own workstation and another for tasks on servers. Profiles with a similar pattern are grouped by observed activity, not by job title - which keeps rules consistent for similar users without manual exception management.

Comparison against attacker tactics

Profiles are set against a library of attacker techniques that Bitdefender Labs keeps up to date. Where a user’s legitimate behaviour and an attacker’s actions do not overlap, PHASR recommends or applies a restriction itself. The block works at action level: WMIC remains allowed for reading system information but is blocked for lateral movement; PowerShell runs but will not execute encrypted commands.

Learning phase and two operating modes

After deployment PHASR learns the environment - typically 30 to 60 days, depending on the monitored rules; if the GravityZone EDR module is in use, historical data shortens that period to minutes. The organization then chooses a mode: Autopilot applies restrictions automatically as behaviour and threats change, Direct Control presents recommendations for review and approval by the security team. A user whose needed tool has been blocked by PHASR can request access with a business justification - the request reaches the administrator as a recommendation.

Key features

Monitoring scope

• Living-off-the-land binaries (LOLBins): PowerShell, WMIC, FTP and other tools pre-installed in the operating system
• Tampering and hack tools used to bypass security controls (e.g. process and memory analysis utilities)
• Software piracy tools used to break licensing
• Cryptominers used for cryptojacking
• Remote administration tools abused for unauthorised access
• Each activity type configured independently: Autopilot, Direct Control or excluded from monitoring

Control and visibility

• Action-level blocking instead of whole applications
• ASM dashboard in the GravityZone console: current attack surface exposure, recommendations by impact, incidents in monitored categories
• Attack surface reduction metrics attached to every recommendation
• Insight into monitored rules and the ability to fine-tune them in Direct Control mode

Profiles for AI agents

• AI assistants and agents running on the endpoint get their own behavioural profile, independent of the user
• Commands spawned by an agent are evaluated against the agent’s profile, not the user’s session - actions forced e.g. by hidden instructions in a document fall outside the profile and are blocked (currently Windows)

Static hardening vs. PHASR

Criterion	Static hardening tools	GravityZone PHASR
Policy	One for all endpoints	Separate per user and endpoint
Unit of blocking	Whole application	A specific action within the application
Change in user behaviour	Manual exception updates	Automatic profile update
Productivity impact	Frequent exceptions and escalations	Restrictions only where the tool is not used
Works alongside a third-party EDR	Depends on the tool	Yes

Supported platforms and licensing

Operating systems: Windows, macOS, Linux (AI agent profiles currently on Windows).

Deployment: as a component of the GravityZone agent (BEST) within the platform, or as a standalone agent in an environment where a third-party EDR/XDR is already running; in both cases managed from the GravityZone console or via API. With the standalone agent the learning phase cannot be shortened with EDR data.

Licence: PHASR is licensed separately - as a standalone licence or as an add-on to selected GravityZone bundles. Whether your bundle includes it, and in which variant, is confirmed by an nFlo sales representative.

Who is it for?

• Organizations with a small security team - hardening that keeps up with behavioural change on its own, without manual exception management
• Companies after an incident involving system tools - closing the attack path the EDR detected too late
• Organizations with a third-party EDR - an additional prevention layer without replacing the existing stack
• MSPs and MSSPs - consistent, behaviour-driven hardening across many client environments without extra staff

How does GravityZone PHASR support NIS2 and the KSC Act?

PHASR adds to Article 21 of NIS2 and Article 8 of the Polish National Cybersecurity System Act (KSC Act) prevention that works before detection - two of the twelve areas whose full mapping we describe in our article on how GravityZone supports NIS2 and the KSC Act:

• Cyber hygiene and attack surface reduction - the per-user behavioural profile restricts system tools, cryptominers and remote administration tools to the actions actually needed at work; the ASM dashboard shows how many attack paths have been closed.
• Cyber resilience and ransomware impact reduction - ransomware groups abuse PowerShell, WMI and PsExec for lateral movement and payload deployment; blocking those actions at profile level takes away their means of spreading before detection kicks in.

Which of these areas is your gap is what we establish in the NIS2 Readiness Check service.

Who is in scope, deadlines and penalties are covered in our NIS2 knowledge hub. GravityZone does not replace an ISMS, formal risk management, audits or the organization’s own accountability for NIS2 and KSC Act obligations - it supports their technical side.

Why deploy with nFlo?

• We plan the learning phase and the choice of mode (Autopilot / Direct Control) around how the organization works
• We review the first recommendations together with your team before restrictions reach administrators’ workstations
• We connect PHASR with your existing EDR/XDR - GravityZone or third-party - without replacing the stack
• We feed attack surface reduction metrics into reporting for security reviews and audits