Identifying and Handling Malicious User Accounts: A Real-World Security Hardening Story

Introduction

Recently, we observed an unusual spike in new account registrations within a short time window. At first glance, the email addresses appeared legitimate. Many belonged to real corporate domains. All accounts were successfully verified using magic-link authentication.

However, something did not feel right.

After deeper investigation into our NGINX access logs and authentication endpoints, we discovered that a significant portion of these signups were originating from Tor exit nodes and proxy networks.

This post explains:

• How we identified malicious user activity
• What signals we analyzed
• How Tor-based abuse works
• What defensive layers we implemented
• The final security hardening architecture we deployed

The First Signal: Abnormal Signup Patterns

The initial red flag was a cluster of new accounts created close together in time.

Observed characteristics:

• Signups occurring minutes apart
• Email domains that looked legitimate
• Magic-link verification completed
• No meaningful product engagement after signup
• Login attempts closely paired with signups

This behavior pattern strongly suggested automation.

Log-Level Investigation

We began analyzing authentication endpoints:

1POST /sign-up
2POST /sign-in

Using NGINX logs:

1grep "POST /sign-up" /var/log/nginx/dflow-access.log*
2grep "POST /sign-in" /var/log/nginx/dflow-access.log*

We extracted:

• IP address
• Endpoint hit
• Timestamp
• Frequency

Patterns discovered:

• Multiple authentication attempts from specific IP blocks
• Several IPs performing both sign-in and sign-up
• Repeated usage of known Tor exit node ranges

Identifying Tor and Proxy Networks

Several IP ranges stood out:

• 185.220.x.x
• 171.25.x.x
• 109.70.x.x

These ranges are commonly associated with Tor exit nodes.

How Tor Works

Tor routes traffic through multiple nodes:

1. Entry node
2. Middle relay
3. Exit node

When traffic reaches our server, we only see the exit node IP.

Even if the attacker is physically located in one country, the visible IP could belong to another country entirely.

Example flow:

Attacker → Node 1 → Node 2 → Exit Node → Our Server

We only see the exit node.

This makes traditional IP tracing unreliable.

Why This Was Concerning

Even though:

• Emails were real
• Magic links were verified
• No brute-force password attempts were detected

The behavioral pattern clearly indicated automated account creation.

Possible motivations included:

• Farming free resources
• Infrastructure abuse
• Testing authentication endpoints
• Platform reconnaissance

The key indicator was clustering. Multiple signups from Tor exit nodes within short time windows, with little to no genuine engagement afterward.

Important Lesson: Verified Does Not Mean Legitimate

Because we use magic-link authentication:

• Bots can generate email accounts
• Receive the magic link
• Automatically open and verify it

Verification proves access to an email inbox. It does not prove human intent.

This was a critical insight.

Security Hardening Plan

We implemented a layered defense strategy.

Layer 1: Cloudflare Turnstile Integration

We integrated Cloudflare Turnstile into:

• Sign-in
• Sign-up

Turnstile characteristics:

• Minimal friction for real users
• Invisible challenge in most cases
• Server-side token verification required
• Resistant to simple automation scripts

Most importantly, validation happens on the backend. Frontend validation alone is never trusted.

Layer 2: Server-Side Token Enforcement

For every authentication request:

1. Turnstile token is submitted
2. Backend verifies the token with Cloudflare
3. If verification fails, the request is rejected

This prevents:

• Direct API abuse
• Scripted bypass of frontend checks
• Automated headless signup flows

Layer 3: Rate Limiting

We analyzed:

• Frequency of POST /sign-up
• Frequency of POST /sign-in
• Repeated attempts per IP

We implemented rate limiting on authentication endpoints to prevent burst automation.

Layer 4: Contextual IP Handling

We chose not to block all Tor traffic globally.

Instead:

• Stricter validation is applied on authentication endpoints
• General browsing remains accessible
• Risk is handled where it matters most

This ensures security without penalizing legitimate privacy-conscious users.

Layer 5: Improved Monitoring

We enhanced logging and monitoring for:

• Failed Turnstile validations
• Repeated signup attempts
• Suspicious IP clustering
• Rapid login attempts

This shifts us from reactive response to proactive detection.

What We Did Not Do

We intentionally avoided:

• Blocking entire countries
• Blanket Tor bans
• Aggressive CAPTCHA across the entire site
• Removing magic-link authentication

Security should be proportional and measured.

Results After Deployment

After deploying Turnstile and backend validation:

• Automated signups dropped significantly
• Suspicious authentication bursts stopped
• No negative feedback from real users
• Infrastructure abuse risk reduced

Authentication endpoints are now substantially more resilient.

Final Architecture Overview

Current authentication flow:

User
→ Turnstile challenge
→ Token generated
→ Backend verification
→ Rate limiting
→ Authentication logic

Only validated and verified requests proceed.

Key Takeaways

1. Email verification does not equal legitimacy.
2. Real domains do not guarantee real users.
3. Tor traffic is not inherently malicious, but authentication endpoints are high-risk targets.
4. Backend validation is mandatory.
5. Logs are your strongest investigative tool.

Closing Thoughts

Security hardening is not a one-time task. It is a continuous process.

As platforms grow, so does their attack surface.

Our approach remains consistent:

• Measure
• Investigate
• Harden
• Monitor
• Improve

If you operate infrastructure, developer tooling, or offer free resources, authentication protection must be treated as foundational.

Security is not optional. It is structural.