Remote execution Policies block risky chains.
RMM abuse prevention
How Lunixar reduces LOLRMM and RMM abuse risk
A legitimate RMM can become an attack vector if it accepts fake tenants, uncontrolled commands, or unlimited installers. Lunixar applies execution policy, time-bound trust, audit, and operational blocking to reduce that risk from the platform.
Active controls and implementation work are separated so pending work is not presented as already available.
Tenant Restriction or blocking when risk appears.
Audit Technical reason retained for review.
Defense model
Abuse is contained before it reaches the endpoint.
- Download + execution patterns are blocked for tenants without extended trust.
- Remote execution trust has a maximum 30-day TTL and audited approval reason.
- Restricted or blocked tenants stop terminal, scripts, schedules, viewer, or login depending on state.
- Blocked-destination rules apply to registration, terminal, scripts, and schedules.
- Blocked events persist the exact policy reason in audit logs.
Active controls
What Lunixar already applies against RMM abuse
These controls come from the current product state and are written as active behavior, not roadmap language.
Remote execution policy
Tenants without extended trust cannot combine remote download and execution. Patterns like irm | iex, curl, wget, msiexec, certutil, rundll32, or regsvr32 are blocked when they form a risky installation or execution chain.
Tenant restriction and blocking
A restricted tenant loses access to sensitive paths such as terminal, scripts, schedules, and viewer sessions. A blocked tenant stops login, API-key reconnect, and dispatch while preserving data isolation.
Policy audit trail
Blocked scripts and executions are recorded in script_logs with WasBlockedBySecurityPolicy and a bounded reason. Trust changes record timestamp, user, and approval reason.
Installer and enrollment limits
Trial installers have limited usage and validity. Enroll tokens have expiration, max-use limits, and independent revocation to cut compromised tokens without affecting the whole tenant.
Managed blocked destinations
Blocked domain, IP, and URL rules are database-backed and enforced during account registration, email changes, terminal input, saved scripts, schedules, and WebSocket execution.
Hardened identity and sessions
TOTP MFA, Argon2id, double-submit CSRF, security headers, Redis-backed login protection, step-up MFA, and revocable sessions reduce the impact of compromised accounts.
Implementation work
Controls that harden the model against LOLRMM
These items are presented as hardening work, not as production-guaranteed features.
Tenant abuse scoring
Signals such as many installers, fast enrollments, frequent blocked commands, suspicious geographies, or residential networks can feed an internal abuse queue.
Known RMM tool catalog
Cataloging AnyDesk, ScreenConnect, MeshAgent, Atera, TeamViewer, TacticalRMM, UltraVNC, NetSupport, and similar tools helps detect bridge or persistence attempts.
Explicit persistence detection
Windows services, scheduled tasks, Run/RunOnce, local admin users, firewall exceptions, reverse tunnels, systemd, and cron are priority patterns.
Tenant allowlist and throttling
For new or unverified tenants, a destination allowlist and stricter execution limits reduce mass-abuse surface area.
Operational response
What happens when an account behaves like an attack vector
01
Policy blocks the action
The command or script is not dispatched when it matches download + execution content, a blocked destination, or a restricted tenant state.
02
The event is audited
The technical reason is retained for internal review, support, and repeated-pattern analysis.
03
The tenant can be restricted
When risk is present, a platform admin can restrict or block the tenant without breaking data isolation.
Abuse channel
Report suspicious activity related to Lunixar
This channel is focused on operational abuse: suspicious installers, unauthorized use, malicious domains, or attempts to use RMM as an attack vector.