Your outsourced SOC sends you a ticket every time someone fails to log in over Remote Desktop. There are dozens a day. Half your team says that is exactly what you pay a SOC for. The other half says it is noise that buries the alerts that matter, and the provider should handle it without bothering you. Somebody has to settle it.
Both sides are partly right. Yes, you want your SOC to detect RDP brute force activity, but you do not want a ticket for every failed login. You want to be told about three things: that RDP is exposed where it should not be, any brute force pattern that is followed by a successful login or targets privileged accounts, and attempts coming from inside your network. Everything else should be handled, tuned and summarised by the SOC, not escalated.
Why the failed logins themselves are a symptom
If a server’s RDP port is reachable from the internet, automated scanners will find it and start guessing passwords. The volume of failures mostly tells you that the door is visible. CISA’s #StopRansomware Guide notes that threat actors often gain initial access through exposed and poorly secured remote services, and recommends limiting RDP use, applying multifactor authentication, enforcing account lockouts after a set number of attempts, and auditing the network for systems using RDP.
So the most valuable report is not “200 failed RDP logins on server X.” It is “server X has RDP open to the internet; here is the fix.” That belongs in a vulnerability or exposure finding with an owner and a deadline, not a daily alert stream.
What a good SOC should escalate
MITRE ATT&CK lists brute force as technique T1110, with password guessing, password spraying and credential stuffing among its sub-techniques. Its detection guidance points to the patterns worth acting on, such as a high volume of failed logons followed by a successful one, and failures spread across many accounts in a short time.
Translated into an escalation policy:
| Situation | What the SOC should do |
|---|---|
| Repeated failed RDP logins from the internet, no success | Block or rate-limit if in scope, raise the exposure as a finding, include in weekly summary |
| Failures followed by a successful login from the same source | Escalate immediately as a likely compromise; investigate the session |
| Password spraying across many accounts | Escalate; check for any successful logins and affected users |
| Failures against admin or service accounts | Escalate with priority, even without success |
| Brute force from an internal IP address | Escalate immediately; an internal source suggests an already compromised machine |
| Successful RDP login at an unusual time, from an unusual location or to an unusual host | Escalate for verification |
On Windows, the raw material for these detections is familiar: failed logon events (4625) and successful logons (4624) with logon type 10 for Remote Desktop sessions. Any competent SOC should be correlating these rather than forwarding them one by one.
Why “report everything” backfires
Alert fatigue is a real operational risk. If your internal team receives fifty low-value notifications a day, the one that says “failed attempts followed by a successful admin login at 3am” arrives looking like all the others. It is also a sign the provider is passing triage work back to you, which is the thing you outsourced.
The opposite failure is just as bad: a SOC that silently suppresses brute force events, never tells you RDP is exposed, and only calls when ransomware is already running.
What to agree with your SOC provider
- A written escalation matrix like the table above, with severity levels and response times for each.
- Exposure reporting: internet-facing RDP, SSH and other remote services listed as findings with recommended fixes.
- Response authority: whether the SOC can block IP addresses, disable accounts or isolate hosts on its own, and when it must call you first.
- Tuning reviews: a monthly check of which alerts were noise and what was changed.
- A summary report: volumes of brute force activity, top targeted systems and accounts, and actions taken, so you can see the work without drowning in it.
- Incident handover: how a confirmed compromise moves into your incident response plan. NIST’s incident response guidance, updated as SP 800-61 Revision 3 in April 2025, treats incident response as part of wider cybersecurity risk management, which is a useful frame for agreeing who does what.
Fix the cause, then the alerts get quieter
- Remove RDP from direct internet exposure; put it behind a VPN or a remote access gateway with MFA.
- Enforce account lockout thresholds and MFA for remote access.
- Restrict which accounts can log in over RDP, and never allow shared admin accounts.
- Enable Network Level Authentication and keep systems patched.
- Audit for forgotten servers and cloud VMs with RDP open.
A hypothetical example: a 120-person manufacturer moves its two exposed RDP servers behind a VPN with MFA. The daily flood of failed logins disappears, and the SOC’s remaining RDP alerts are the rare internal or post-success cases that genuinely need a human.
If you are still choosing a provider, our guide to deciding what you are buying before asking for MSSP recommendations covers scope and service levels, and why most companies cannot staff a 24/7 SOC themselves explains the economics.
A SOC that tells you what matters
The right answer to the RDP argument is a SOC that detects everything, escalates selectively and helps close the exposure causing the noise. AB7 Solutions provides managed SOC and security monitoring with agreed escalation matrices, alert tuning and clear monthly reporting, alongside vulnerability assessment and penetration testing (VAPT) and firewall and server hardening to remove exposed services like internet-facing RDP. If your current provider’s detections are sound and only the escalation rules need work, we will help you fix that rather than replace them.
Send us a sample of the alerts you receive and your current escalation rules, and we will show you what should reach your team and what should not.
Email: ab@ab7solutions.com | director@ab7solutions.com
Phone: +91 9878067778 | +1 321 341 7733
Website: www.ab7solutions.com
Sources: CISA, #StopRansomware Guide; MITRE ATT&CK, T1110 Brute Force; NIST, SP 800-61 Revision 3 (April 2025).
[…] For choosing a SIEM specifically, see how to choose a SIEM without regretting it in 18 months, and for what your SOC should escalate from these tools, whether your SOC should report RDP brute force attempts. […]