In our recent post, The Internet’s Best Map Is Now Its Clearest Risk Signal, we introduced Censys Reputation Score and why it matters: it offers a faster way to apply judgment to the public infrastructure behind real security incidents.
This post is the next step. It’s the first in a series on a simpler question: what does that look like inside common SOC alerts?
Each entry in this blog series will focus on a different category of signals that flow into an enterprise SIEM. We will take a few representative alerts, treat the alert itself as the center of gravity, and show where Censys helps.
Sometimes that means using Reputation Score to make a faster close-versus-escalate decision.
Sometimes it means pulling in Censys ARC intelligence to understand whether the external host behind the alert looks benign, suspicious, or actively dangerous.
Sometimes it means helping a junior analyst make a better call, or giving a more senior responder a better starting point for scoping.
Sometimes it means giving AI and automation better context so they do not make brittle decisions from raw indicators alone.
For entry one, we are starting with identity and access alerts: IAM, SSO, MFA, VPN auth, federation logs, and privileged-access workflows. These alerts are everywhere. They are also easy to get wrong.
Triaging Identity and Access Alerts
Over the last decade, identity platforms like Duo, Okta, and Microsoft Entra have become central to how enterprises authenticate users, enforce policy, and make access decisions. This means IAM alerts now sit much closer to the front door of the business than many traditional security signals.
An external IP in an auth event can mean a traveling employee, a VPN exit node, a cloud-hosted login proxy, a residential proxy, attacker infrastructure, or something in between. The diversity and urgent nature of these alerts make sound judgement critical.
I present: three examples. Each one starts with the alert. The Censys enrichment then takes us home. Showtime!
Example 1: Successful identity login from a first-seen external IP
- Source: Okta Risk Engine
- Severity: Medium
- User: jane.doe@company.com
- Application: Microsoft 365
- Event: Successful login after MFA challenge
- Source IP: {redacted}
- Risk factors: First-seen IP, new ASN, unusual location
- Disposition: Allowed
This is one of the most common identity alerts in the SOC: a successful login from infrastructure the organization has not seen before.
The alert tells you just enough to be dangerous. A user signed in successfully. MFA was completed. The IP is new. The ASN is unfamiliar. The login might be completely legitimate. It might also be an early sign that the user is authenticating through infrastructure they do not normally use, or that an attacker is operating through a proxy or other external service.
This is where analysts lose time. Not because the alert is hard to understand, but because the external IP is not self-explanatory.
The first question is simple: what is this host?
The second question is harder: does it deserve concern?
What does Censys see?
Something a defender could easily miss if they only treated the IP as a generic login source.
On port 7000, the host was serving a web interface for VPNBrute v1.3.0, a tool associated with brute forcing VPN credentials. Censys classified the host as a SECURITY_TOOL with an INITIAL_ACCESS tactic, based on content in the page body and login page, including a visible dashboard and login interface.
That changes the meaning of the identity alert.
A successful Okta login from a first-seen IP is easy to wave away as travel, a consumer VPN, or normal user variation. A successful login from infrastructure actively exposing a VPN credential brute-forcing tool is different. It does not prove the authentication was malicious on its own, but it changes the burden of proof. The alert is no longer just unusual. It is tied to infrastructure with a clear identity-abuse use case.
For a Tier 1 analyst, that is enough to justify escalation. For a more senior responder, it is enough to start asking better questions immediately: has this user seen pressure on other identity surfaces, do we have other auth attempts from related infrastructure, and should we treat the session as a likely compromise path instead of a routine risky login?
How can Censys see this?
This is also a good example of why broad, frequent Internet scanning matters. The interesting service here was not on a standard web port. Censys observed the VPNBrute interface on port 7000, along with application paths like /login, /api/clients, /api/result, and /api/logs, which gave analysts much more than a bare IP lookup.
At the time of writing, the service did not appear in Shodan, which hadn’t scanned this host for three days.
Example 2: MFA fatigue or repeated failed authentication followed by success
- Source: Microsoft Entra ID
- Severity: High
- User: finance.admin@company.com
- Application: Finance SSO portal
- Event: 11 failed MFA challenges followed by successful authentication
- Source IP: {redacted}
- Risk indicators: Repeated push denials, unusual sign-in pattern, successful auth after failures
- Disposition: Allowed
This is the kind of alert that can burn analyst time if the source IP looks suspicious at first glance.
What does Censys see?
In this case, Censys showed some of the same signals that would make an IAM platform uneasy: the host was marked as anonymous and VPN-related, and it was a first-seen external login source. But the broader host context pointed in a more benign direction. The IP sat on a Deutsche Telekom residential range, resolved to a dynamic consumer-style hostname, exposed only one service, and that service appeared to be a DrayTek Vigor router providing PPTP connectivity on port 1723. Its Reputation Score was just 10 / BENIGN, with the score driven only by anonymization-related evidence.
That does not make the identity alert irrelevant. It explains it. The login still looks unusual to Entra, but the source host looks much more like personal or small-office VPN infrastructure than attacker-controlled login infrastructure. That gives an analyst a reasonable basis to downgrade the event instead of escalating it as likely compromise.
Example 3: Privileged VPN or administrative access from a first-time external IP
- Source: VPN / PAM platform
- Severity: High
- User: it-ops-admin
- Access type: Successful privileged VPN authentication
- Source IP: {redacted}
- Risk factors: First-seen IP, no prior device match, privileged account
- Disposition: Session established
This alert is different for one reason: the account itself raises the stakes.
A first-seen IP for a normal employee may be noise. A first-seen IP for a privileged user should be treated with much more care. Even if the event is legitimate, analysts need a better answer, faster.
What does Censys see?
In this case, Censys showed that the source host was not just an unfamiliar external IP. It exposed FRPS on port 7000, identifying it as an FRP proxy server with a self-signed certificate and an application response indicating a token mismatch during login. The same host also exposed SSH, Syncthing’s admin interface on port 8384, and additional web activity on port 8080. It resolved to {redacted}, sat in AEZA infrastructure, and carried a BULLETPROOF label in Censys.
That changes the posture of the alert immediately.
A privileged login from a first-seen IP is already concerning. A privileged login from infrastructure running FRP, a tool used to tunnel and expose internal services, is much harder to explain away. It does not prove the session is malicious on its own, but it tells the analyst that the source host looks more like operator-controlled remote-access infrastructure than a normal employee access point. This goes from “watch this” to “scope this now.”
Now the workflow can expand beyond a score or a single verdict. The initial enrichment tells you the host deserves scrutiny. The surrounding context helps you scope it:
- FRPS on 7000 suggests tunneling or proxy infrastructure.
- Syncthing on 8384 exposes another administrative surface, complete with a named version and a public hostname.
- The host sits in infrastructure that is already operationally notable for defenders.
The alert is the starting point. Censys helps answer what kind of infrastructure is behind it, why it matters, and how much urgency the analyst should assign to the investigation.
Conclusion
Identity alerts are rarely about identity alone.
The user, the app, the factor, and the login result all matter. But when those alerts involve Internet infrastructure, the host behind the event can change the story just as much as the authentication telemetry itself.
Reputation Score helps security teams make faster, more consistent judgments about the public hosts behind common alerts. Censys ARC and the broader Censys Internet Map add the rest: infrastructure context, threat history, vulnerabilities, and pivots that help analysts understand not just whether a host looks risky, but why.
For identity alerts, that means less guesswork around first-seen IPs, proxy or VPN infrastructure, suspicious hosting, and privileged access events. It means junior analysts get better judgment. It means L2 and L3 responders start with better scope. It means hunters and detection engineers can build stronger logic from real Internet context. And it means AI and automation workflows have a better chance of being useful instead of noisy.
This is the first entry in the series. Next time, we will take the same approach with another common alert source and again start with the alert itself. In the meantime, explore other ways to modernize your SOC.
