Server Security Health Check: What It Looks At
6 min read
The call usually starts the same way: this machine has been behaving oddly. CPU pinned at eighty or ninety percent with nothing running, remote sessions crawling, or one morning a login screen showing an account nobody remembers creating. Sometimes that is ageing hardware or a setting nobody ever tuned. Sometimes it means somebody has been mining on your host for a month and left a way back in. A health check exists to establish what is actually there, before you decide whether to rebuild the machine.
1. The symptoms worth taking seriously
Most clients feel that something is wrong before they go and look at any logs. The awkward part is that every one of these symptoms has an innocent explanation on its own: full CPU can be a scheduled backup, a slow connection can be a saturated link. What deserves investigation is two or three appearing together, or all of them starting in the same week.
Different problems leave different traces. Cryptominers are relatively loud: sustained high load plus outbound connections to a mining pool is hard to hide. Backdoors and remote-access tools are far quieter. They consume almost nothing day to day and only show up in the accounts, the scheduled tasks and the ports left listening. A machine that feels fine is not evidence of a machine that is clean.
Six symptoms worth a second look
- Load that never comes down. CPU or GPU running hot for long stretches while business volume is unchanged, including overnight.
- Odd outbound traffic. Connections to hostnames nobody recognises, traffic that goes out on a fixed interval, or long-lived sessions on unusual ports.
- Accounts you do not recognise, or an existing account that has quietly joined the administrators group.
- Antivirus switched off. Real-time protection disabled, or strange folder paths added to the exclusion list.
- Scheduled tasks nobody created, especially ones that trigger at boot or every hour.
- Logs cleared, or a gap where a particular period should be.
2. What the check actually covers
The work is an inventory: list what is on this host right now, then decide whether each item belongs. I run tooling I built for this, with administrator rights on the machine, collecting running processes, patch state, accounts and installed software in one pass.
The tool collects and compares; a person does the judging. There is no universal answer to whether a given process should be on a given machine, because it depends on what the machine is for. Remote-control software on an IT team's workstation is unremarkable. The same software on the accountant's PC is worth a conversation.
| Area | What gets looked at |
|---|---|
| Running processes | Name, full path of the executable, the account it runs as, the parent process. Anything running from a temp folder or a user directory gets extra attention |
| Patch state | OS version, updates installed and missing, how long since the machine was last patched |
| Accounts and rights | Which accounts exist, who sits in the administrators group, password policy, dormant accounts and leavers nobody removed |
| Installed software | Badly out-of-date components, remote-control tools, cracked software, utilities of unclear origin |
| Listening services and ports | What is listening, and whether it is reachable from the internet. Remote desktop, remote access and database ports matter most here |
| Scheduled and auto-start items | Scheduled tasks, services, the startup folder and the registry run locations |
| Logs | Successful and failed logins, account creation and privilege changes, services restarting abnormally and repeatedly |
3. What checking processes against VirusTotal does
Once the process list is collected, I take a fingerprint of each executable and check it against VirusTotal, which aggregates the verdicts of several dozen antivirus engines. When a file is flagged as malicious by a dozen of them, the signal is unambiguous.
Sending a fingerprint instead of the file is a deliberate choice. What leaves your network is a short code derived from the file contents, not the file itself, so no company data goes anywhere. That distinction matters a lot when the machine belongs to a client rather than to me.
Reading the result means looking at how many engines flagged the file and whether they agree on what it is. A single engine returning a generic verdict is often a false positive, and in-house or niche software gets mislabelled that way regularly. A file that a dozen engines independently identify as the same trojan needs no further debate.
4. Health check, vulnerability scan and antivirus are three different things
People price all three as if they were one service, but they look at different things at different moments. Confusing them costs money in the wrong direction: assuming antivirus makes a health check unnecessary, or assuming a scan tells you what has been planted inside the machine.
| What it looks at | When | Blind spot | |
|---|---|---|---|
| Antivirus / EDR | Files and behaviour | Resident, in real time | Custom malware and memory-only attacks; if it gets switched off you may never notice |
| Vulnerability scan | Versions and configuration | Periodic, from the outside | Only finds known weaknesses, and says nothing about what is already inside |
| Security health check | Current state and configuration | One-off, from the inside | Blocks nothing in real time, and reflects only the state at the moment it ran |
The three complement each other. A health check answers what is wrong with the configuration today, scanning tracks whether known weaknesses have been closed, antivirus does the day-to-day interception. None of the three is incident forensics. Establishing a timeline of an intrusion and how far it spread is deeper, slower and considerably more expensive work.
5. What the report gives you
The deliverable is a report: the inventory plus hardening recommendations, each item carrying a risk rating and the reasoning behind it. The ratings exist to give you an order of work, not to alarm you. Small companies have limited IT capacity, and fixing twenty things at once is not realistic.
High-risk items usually share one property: they can be exploited directly from outside. Remote desktop open to the whole internet, an operating system unpatched for years, an administrator account whose owner nobody can name. Those go to the top of the list.
Each finding sets out the current state, the risk rating, the likely impact and what to do about it. The report also carries the fingerprint results for suspicious processes with an explanation of how they were read, an account inventory, a list of exposed services, and the patch gap. Recommendations are grouped by feasibility, separating what you can change this afternoon from what needs downtime or an architectural change.
6. What you need to provide, and whether it disrupts anything
A health check needs administrator rights, because reading the process list, the account data and the system configuration requires them. That is the part clients hesitate over most, so the scope is worth stating plainly: the run only reads and inventories. Nothing is reconfigured, no files are deleted, no services are restarted. Patching and hardening get scheduled separately, after you have reviewed the findings.
One pass usually takes between a few minutes and a quarter of an hour depending on how much software is installed, and the load it puts on the machine is comparable to an ordinary system inventory command. No downtime is required. If the host is already running close to its limit, we can book an off-peak or overnight slot. It can run remotely or on site, whichever your network policy allows.
7. How often is reasonable
A health check reflects the state of the machine on the day it ran. A few months later, with new software installed and new services opened, that state has moved. Once or twice a year is a sensible rhythm, starting with the machines that matter most: file servers, the ERP box, anything serving the public internet.
A few moments justify jumping the queue regardless of the schedule. Do one when a new machine goes live, or when you take over an existing host from a previous supplier, so you have a baseline. Do one promptly when the symptoms above appear. Do one after staff changes, to confirm that a leaver's accounts and remote access are genuinely gone. And do one after major system work: a version upgrade, a move to a new facility, or a new service exposed to the outside.
Once patching and account reviews are part of your routine operations, the health check drops back to a verification role and no longer needs repeating every quarter. That is the healthier position to be in: somebody is minding the machine day to day, and the check simply confirms nothing was missed.
A server security health check hands you a clear picture of the current state and a prioritised set of hardening steps, which turns a vague feeling that the machine is off into a list of tasks you can work through. It cannot promise to find every piece of malicious software; custom-written or memory-only attacks can still slip past an inventory and a fingerprint comparison. If the inventory shows the host has already been breached, what you need next is incident investigation and forensics, and I will tell you so directly and help you work out where to go from there.
Common questions
- My server CPU is permanently maxed out. Does that mean a cryptominer?
- Not necessarily. Backup jobs, database index rebuilds, constant paging caused by insufficient memory and runaway applications all produce sustained high load. What settles it is which process is consuming the CPU, where its executable lives, whether load drops off-peak, and whether the machine is talking to addresses nobody recognises. A health check puts all of those side by side so you have grounds for a decision rather than rebuilding on a hunch.
- After a health check, can you guarantee the server has no malware?
- No. The check is an inventory plus hardening advice, covering running processes, account privileges, scheduled tasks, exposed ports and patch state, with fingerprint comparison on the processes. Malware written for your organisation, samples too new to be catalogued, and attacks that never touch disk may all go unflagged. The check narrows the blind spots and puts the obvious risks in front of you. It cannot claim to have emptied the machine.
- Will it disrupt operations? Does the server need downtime?
- No downtime. The process reads system information with administrator rights: nothing is reconfigured, no files are deleted, no services are restarted, and a single host normally takes a few minutes to a quarter of an hour. If the machine is under heavy load we can run it off-peak or overnight. Patching and hardening happen afterwards on your schedule, and I do not change settings during the check itself.