A simple control that still works
Shared drives are one of the easiest ways for malware or just bad decisions to spread.
- Someone plugs in a USB.
- Copies a few files.
- Another user opens something from the share.
That’s all it takes!
In many environments, especially ships and small offices:
- Shared folders are heavily used
- Users trust what’s on them
- And files get executed directly from the network
This makes file shares a quiet distribution point for risk
The overlooked problem: “harmless” file types
Not all risky files look dangerous.
Some of the most commonly abused types include:
.lnk (Windows shortcut files)
.bat (batch scripts)
.ps1 (PowerShell scripts)
.js (JavaScript)
.vbs (VBScript)
.cmd (command scripts)
Take lnk files as an example:
They look like shortcuts. They often have normal icons.
But they can:
- Launch scripts
- Execute hidden commands
- Redirect to malicious locations
To a user, they look harmless To the system, they can trigger execution
Doesn’t antivirus handle this?
Sometimes.
But not always, and not immediately.
Antivirus tools typically rely on:
Signatures Behaviour analysis Known patterns
That means:
New or modified files may not be flagged straight away Some file types (like .lnk) may not be treated as high risk
The result: a gap between arrival and detection
The simple control: block them at the file server
This is where File Server Resource Manager (FSRM) comes in.
FSRM allows you to:
- Define file types
- Apply rules to shared folders
- lock files before they are written to disk
Not after execution Not after detection But at the point of entry
What to block (practical baseline)
A good starting point:
*.lnk
*.bat
*.ps1
*.js
*.vbs
*.cmd
These are rarely needed on shared drives and when they are, it should be controlled.
What this actually prevents
Using FSRM in this way helps stop:
- Users accidentally running scripts from shared folders
- Basic malware delivery via USB → share → user
- Shortcut-based attacks disguised as normal files
- Script-based payloads being staged centrally
It removes an entire class of “easy wins” for attackers
Why this works so well
Because it’s:
- Centralised - enforced at the server
- Simple - no agents or complex deployment
- Predictable - blocks by rule, not detection
And most importantly:
It doesn’t rely on users making the right decision
Limitations
FSRM is not a silver bullet.
It does NOT:
Inspect file contents Detect renamed files (e.g. .ps1 → .txt) Replace antivirus or endpoint protection
It CAN be bypassed if used alone. This is a control layer, not a full solution
Where this fits in a real setup
FSRM works best when combined with:
- Endpoint protection (e.g. A9X Defender)
- USB control (blocking unknown devices e.g. A9X USB Manager)
- Logging / monitoring (event collection, SIEM e.g. A9X Watchdog)
Think of it as:
A simple gate that removes unnecessary risk before it spreads
Why this matters in real environments
In maritime and small office setups:
- Infrastructure is inconsistent
- Users are not security-trained
- Bandwidth is limited
- Centralised security tools are often missing
You don’t need complexity, you need reliable controls
FSRM fits that model perfectly.
Bottom line
Blocking risky file types on shared drives is:
- Easy to implement
- Low overhead
- High impact
It won’t stop everything.
But it will stop a lot of the simple, common, and avoidable problems.
And in most environments—that’s exactly where the real risk is.
And if users don’t need to run scripts or shortcuts from shared drives…don’t allow them to exist there!