Managed SOC and CrowdStrike Hardening for a US Manufacturing Software Vendor

Background

A US software vendor serves manufacturers through a set of customer-facing web portals, quoting tools and automated file exchange with partner companies. The whole business runs on three internet-facing Windows servers: roughly one hundred IIS sites and application pools, several Microsoft SQL Server instances, dozens of .NET Windows services, and an SFTP endpoint that partners push order files to around the clock.

The company had been hit by ransomware. In the aftermath it had licensed CrowdStrike Falcon and installed the sensor on all three servers, but the tenant was running close to factory defaults: no file-system containment, the Falcon host firewall not managing the servers at all, and no one watching detections. The servers accepted remote administration, SQL, SMB and SSH from anywhere on the internet. The owner’s brief was direct: make it as secure as possible, and do not take the business down doing it.

CyberneticsPlus was engaged in August 2026 for two linked pieces of work: harden the CrowdStrike deployment against a repeat of the ransomware event, and put the estate under 24/7 monitoring through the CyberneticsPlus Managed SOC.

Assessment

The engagement opened with three deliverables in the first week.

Ransomware threat intelligence and EDR gap report. Current ransomware tradecraft against exposed Windows servers was mapped against the tenant’s actual Falcon configuration. The result was a phased hardening plan with a reversal step for every change, so nothing would be applied without a known way back.

Malware scan. A tenant-wide review confirmed no active infection remained from the original incident.

Vulnerability scan. The SOC’s vulnerability detection produced per-server reports. The headline was that each server’s risk was dominated by a single package: on the busiest server, 635 of 665 detected CVEs came from one abandoned Firefox ESR install, and on the other two, unpatched SQL Server setup components accounted for over ninety percent. The remediation list was therefore short: three package upgrades removed the bulk of the exposure.

The most important finding came later, from thirty days of authentication telemetry rather than from assumptions. Remote Desktop, which the client and most playbooks would have treated as the primary risk, had zero successful and zero failed logons in a month. The surfaces actually under attack were different: around 49,000 failed SSH logins and 60,000 failed SMB/NTLM logins per week, plus a steady low-rate SQL Server brute force. One server also accepted anonymous null-session logons from the internet. The firewall plan was rewritten around what the data showed.

What Was Done

Phase 1 to 3: CrowdStrike Falcon prevention hardening

Changes were made one at a time on the live Default policy, each followed by a monitoring window and recorded in a configuration change record with a reversal plan.

• File System Containment enabled, the control that stops a ransomware process from encrypting beyond the first files it touches. A 24-hour review showed zero false positives across the estate.
• Uninstall and maintenance protection confirmed on, with per-host maintenance tokens retained rather than bulk mode, the stricter option for a small estate. Tokens are generated and held by the client, never by CyberneticsPlus.
• Sensor update policy set to auto-update at N-1, so the sensors track current releases without being first to a new build.
• Machine-learning sliders compared against CrowdStrike’s optimal-protection template. Detection and prevention were already at Aggressive across cloud, sensor and on-demand scanning, so no change was made. Pushing production servers to Extra Aggressive was deliberately declined.
• Boot configuration database protection was the one real gap found in the comparison. It was enabled on all three hosts.
• A Fusion SOAR workflow was published so every endpoint detection emails the client immediately, with no severity filter, because on a three-server estate a missed low-severity detection costs more than the noise.

Falcon host firewall: from unmanaged to data-driven default deny

The Falcon firewall was not managing the servers at all; the locked default policy had enforcement off, which left the native Windows firewall in control with no central visibility. A custom policy was created with default-deny inbound and outbound and rolled out in monitor mode first, so every packet that would have been blocked was logged but allowed through.

Two weeks of “would be blocked” logs then drove the rule set. The policy moved to enforcing in three steps:

1. Blocklist plus allowlist, with a catch-all allow-and-log rule beneath them. Default deny is pre-positioned as the foundation; the catch-all is the safety rule that prevents a black-hole on a misconfiguration. Internet-wide scanning IP ranges were denied outright.
2. Management-port restriction, driven by the thirty-day telemetry above. Remote Desktop was closed on all three servers because nothing used it. SSH was closed on the one server that had shown zero successful sessions in a month, while the genuine SFTP host stayed open pending the client’s partner list.
3. SMB held for a client decision. The telemetry showed that all real administration happened over SMB from a roaming laptop that had appeared from nine different addresses in thirty days. A strict allowlist would have locked the administrator out seven times. CyberneticsPlus recommended VPN or zero-trust access for the administrator rather than an IP allowlist, and the anonymous-logon exposure was routed to a Windows hardening fix rather than a firewall rule.

Every firewall change was made in the Falcon console with the rollback documented as a single action: re-enable monitor mode and save.

Managed SOC onboarding

All three servers were enrolled into the CyberneticsPlus Managed SOC under an isolated tenant, using a signed installer the client ran themselves. Because CrowdStrike already covered process-level EDR, the SOC was scoped to complement it rather than duplicate it: SIEM log aggregation, CIS benchmark compliance scanning (around 350 checks per server), targeted file-integrity monitoring, continuous vulnerability detection, and correlation across sources Falcon does not see.

Log sources: Windows Security, System and Application channels; Microsoft Defender operational logs; IIS access logs for every site (using a wildcard, because IIS site IDs on a mature server are never sequential); SQL Server error logs; and Windows OpenSSH, which required a short client-side runbook to switch sshd to file logging and a custom decoder on the SOC side, since the Windows OpenSSH format is not Linux syslog.

CrowdStrike detections ingested into the SIEM. A three-minute poll pulls every Falcon detection into the same case pipeline as the SIEM alerts, so the SOC sees what Falcon blocked alongside what the logs show.

Compliance control mapping at ingest. Every alert is tagged to the ISO 27001, SOC 2 and CMMC controls it evidences as it enters the SIEM, so the client’s audit evidence accumulates from the monitoring itself rather than being assembled by hand before an assessment. Monitoring ties detections to controls; it does not by itself make anyone compliant, and the client’s reports say so.

Detection rules tuned to this estate, each mapped to MITRE ATT&CK:

EDR watchdog:        Falcon service stopped or crashed; Defender real-time
                     protection disabled or reconfigured
Defense evasion:     Security log cleared (1102); audit policy changed
Persistence:         New service installed (7045); scheduled task created (4698)
Account abuse:       New local user; user added to Administrators or RDP group
SQL Server:          Service stopped; 10 failed logins in 2 minutes;
                     successful login following a brute-force burst
Web shell:           Server-side script URL carrying an OS-command token;
                     executable script requested from an upload directory

The web-shell rules were validated against real production URLs from the client’s busiest portal before going live, so a legitimate admin endpoint that polls every few seconds produces no alert.

Automated attacker blocking

The two systems were joined into a closed loop. When the SOC sees five or more failed logins within fifteen minutes from a single external address, across SQL, SMB, RDP or SSH, that address is appended to the Falcon firewall deny rule via the CrowdStrike API within the next five-minute cycle. Entries expire after seven days so the rule does not grow without bound. A static allowlist of the client’s own addresses and partners is never blocked.

The loop was hardened after its first false positive. A partner’s automated SFTP client retried a stale password six times and was blocked four minutes later. The fix was a success-login guard: any address with a successful authentication on the estate in the previous 24 hours is skipped and flagged to the SOC as a probable user with a stale password, instead of being denied. The partner was restored and allowlisted the same day.

Tuning out the noise

The first week of monitoring produced 104 “possible ransomware” alerts across the three servers, every one false. The rule counted registry changes alongside file changes, and Windows registry churn from firewall boot policy, ASP.NET and background activity tripped the threshold constantly. The rule was rescoped to file changes only, then replaced with an evidence-driven approach: the SOC’s AI triage now fetches the underlying file-integrity events before assessing a ransomware alert, and can downgrade a registry-churn false positive itself rather than restating the rule name as fact.

Across all rule categories, escalations to the client went from dozens per day to a handful per week without lowering any detection threshold.

Results

Zero production downtime across five weeks of changes to a live estate, including moving the host firewall from unmanaged to enforcing default deny.

Attack surface closed where it mattered. Remote Desktop removed from the internet on all servers, SSH removed from the one server that never used it, internet-wide scanner ranges denied, and a live blocklist that fluctuates between roughly 350 and 500 auto-blocked attacker addresses under seven-day expiry. Blocked addresses go silent within one sensor propagation cycle; the SOC verified this per address before declaring the mechanism working.

A false alarm that would have caused an outage was disproved with evidence. Midway through the engagement the client’s SFTP service began dropping partner connections and CrowdStrike was blamed. Falcon firewall activity showed the SSH port was being allowed, not blocked, and there were zero detections and zero containment actions. The root cause was an OpenSSH chroot permission problem on a newly created account. Disabling CrowdStrike, which had been proposed, would have removed the ransomware protection and fixed nothing.

Vulnerability exposure reduced with three upgrades. Because each server’s CVE count was traced to a single package, the client’s remediation list was three items rather than nine hundred. Weekly per-server vulnerability reports are generated every Friday and reviewed by an analyst before release. That review earned its keep early: the client noticed one package’s recommended upgrade version was lower than the newest CVE required, and the report logic was corrected to recommend the highest fix version across all of a package’s CVEs rather than the first one found.

Operational problems found, not just attackers. Monitoring surfaced issues no scanner would have flagged: an SFTP password stored in plaintext in an application configuration file, a low-and-slow pattern of SQL Server logon failures consistent with a service running on stale credentials rather than an attacker, and a partner integration hammering a portal endpoint with malformed requests from a broken polling client. Each was handed to the client as a finding with a recommended fix.

Ongoing coverage. The estate generates around 200,000 security events per week into the SOC. The client receives a weekly summary, immediate notification of anything critical, and an agent-disconnection alert within fifteen minutes if a server stops reporting. Remaining items, SMB access for the roaming administrator and the anonymous-logon hardening, sit with the client as documented decisions rather than open risks nobody owns.