Check your RADIUS server's BlastRADIUS exposure

BlastRADIUS (CVE-2024-3596) lets an attacker who can sit between a NAS and the RADIUS server forge a valid response, because classic RADIUS/UDP doesn't require the reply to be signed. The defence is the Message-Authenticator attribute — and you can check in one command whether your server actually uses it.

1. Run the check

There's no special mode to enable: the Message-Authenticator posture check is part of the standard radius test run, and it needs no credentials — just a reachable server and the shared secret:

# the BlastRADIUS posture check runs by default — no special flag, no login needed
authhound-probe radius test --server radius.corp.com --secret-file /etc/authhound/secret

The probe sends one normal authentication and inspects the reply. It's read-only and sends nothing an ordinary client wouldn't — it's checking posture, not attacking anything.

2. Reading the verdict

• PASS The server signs its replies with Message-Authenticator. The BlastRADIUS forgery path is closed for this server.
• WARN The reply isn't protected by Message-Authenticator — the server is exposed to the BlastRADIUS class of attack. It's a WARN, not a FAIL, because auth still works today; under --strict it becomes a failure.

For monitoring, run it with --strict so the exposure trips your alerting instead of passing quietly:

# in monitoring, --strict turns the Message-Authenticator warning into exit 1
authhound-probe radius test --server radius.corp.com \
  --secret-file /etc/authhound/secret --strict

3. If you're exposed

• Require Message-Authenticator on both the server and the NAS. Current FreeRADIUS and patched Windows NPS builds add and require it; the exact server-side signature and fix are on the KB page: FreeRADIUS invalid/missing Message-Authenticator.
• Move to RadSec where you can. RADIUS over TLS (TCP/2083) wraps the whole exchange in TLS, which removes the UDP forgery surface BlastRADIUS relies on. The probe tests a RadSec endpoint directly:

  # RadSec (RADIUS over TLS, TCP/2083) removes the UDP attack surface entirely
  authhound-probe radsec test --server radius.corp.com --server-name radius.corp.com

• Re-run after the change — a PASS on the Message-Authenticator check (or a clean radsec test) is your confirmation it took.

Related

• Invalid / missing Message-Authenticator

  The server-side log signature and the config that requires the attribute — the BlastRADIUS fix.

• Wire the probe into your RMM

  Put the --strict posture check on a schedule so a regression is caught automatically.

• Flag reference

  The radsec test subcommand and every flag it takes, generated from the binary.