Honeypots & Trust Frameworks: Deception & Trust in Cybersecurity

TAKEAWAYS:

• Honeypots are decoy systems designed to lure attackers, classify threats, and study malware—low-interaction (simulated) vs. high-interaction (fully functional) types exist.
• Trust frameworks rely on authentication (Kerberos, tokens), authorization (access rights), and PKI (digital certificates) to secure transactions (e.g., eSewa payments).
• Token-based auth (JWT/OAuth) replaces passwords with short-lived tokens, reducing credential theft risks (used by Khalti, Daraz).
• Kerberos uses symmetric encryption and tickets for secure authentication in enterprise networks (e.g., NTC’s internal systems).
• Honeypots help detect APT attacks (e.g., a fake NEPSE trading server trapping hackers) while trust frameworks enable cross-organization trust (e.g., banks sharing fraud data).
• Exam focus: Define access rights, trust frameworks, and honeypot types; explain Kerberos/OAuth workflows with diagrams.

1. Honeypots: The Cybersecurity Decoy

Honeypots are intentional traps designed to attract cybercriminals, study their tactics, and gather threat intelligence. Unlike firewalls or IDS, they do not block attacks but observe and analyze them in a controlled environment.

Why Use Honeypots?

• Threat intelligence: Collect malware samples, attack patterns (e.g., how hackers exploit Ncell’s old servers).
• Early warning: Detect zero-day exploits before they hit production systems.
• Resource diversion: Waste attacker time/money on fake systems (e.g., a decoy Daraz database).
• Compliance: Meet security audits by proving proactive monitoring.

Types of Honeypots

How Honeypots Work: A Worked Example

Scenario: A Khalti payment gateway deploys a high-interaction honeypot mimicking its transaction server.

1. Attacker scans for port 443 (HTTPS) and finds the honeypot.
2. They attempt SQL injection on a fake login page.
3. The honeypot logs the IP, payload (' OR 1=1 --), and timing.
4. Security team blocks the IP and analyzes the exploit for Khalti’s real servers.

sequenceDiagram
    participant Attacker
    participant Honeypot
    participant SecurityTeam
    Attacker->>Honeypot: Scans port 443 (fake Khalti server)
    Honeypot-->>Attacker: Returns fake login page
    Attacker->>Honeypot: Sends SQLi: ' OR 1=1 --
    Honeypot->>SecurityTeam: Logs attack (IP: 192.168.1.100, Payload: SQLi)
    SecurityTeam->>Firewall: Blocks 192.168.1.100

Real-World Honeypot Deployments

• Google’s Project Honey Pot: Tracks spam botnets by deploying fake email servers.
• NTC’s Darknet Honeypot: Monitors DDoS tools targeting Nepal’s telecom infrastructure.
• Banking Sector: Fake ATM networks to study skimming malware (e.g., GlobalPayments breach).

2. Trust Frameworks: Building Secure Digital Trust

Trust frameworks enable secure interactions between entities (users, organizations, systems) by verifying identities and permissions. They are critical for:

• E-commerce (e.g., Daraz’s buyer-seller trust system).
• Government services (e.g., eSewa’s digital signatures).
• Cross-organization data sharing (e.g., banks verifying KYC via Nepal Rastra Bank).

Core Components of Trust Frameworks

1. Authentication: Proving identity (e.g., Kerberos, OAuth, biometrics).
2. Authorization: Defining access rights (e.g., RBAC: Role-Based Access Control).
3. Audit Logs: Recording actions for accountability (e.g., NEPSE’s trade logs).
4. Public Key Infrastructure (PKI): Uses digital certificates (e.g., SSL/TLS for HTTPS).
5. Federated Identity: Single sign-on (SSO) across systems (e.g., Google/Facebook login).

Key Trust Models

How Trust Frameworks Work: Kerberos Example

Scenario: A NTC employee accesses an internal database using Kerberos.

sequenceDiagram
    participant User
    participant AuthServer
    participant TicketGrantingServer (TGS)
    participant DatabaseServer
    User->>AuthServer: Requests TGT (with password)
    AuthServer-->>User: Returns TGT (encrypted)
    User->>TGS: Sends TGT + service request
    TGS-->>User: Returns Service Ticket (for DB)
    User->>DatabaseServer: Sends Service Ticket + request
    DatabaseServer-->>User: Grants access

Steps:

1. User sends credentials to Authentication Server (AS).
2. AS issues a Ticket Granting Ticket (TGT) (encrypted with KDC’s key).
3. User requests access to Database Server; TGS issues a Service Ticket.
4. Database verifies the ticket and grants access.

Why Kerberos?

• No password transmission over the network.
• Time-stamped tickets prevent replay attacks.
• Used by Microsoft Active Directory, Linux MIT Kerberos.

3. Token-Based Authentication: The Future of Logins

Traditional passwords are weak (easily stolen via phishing). Token-based auth (e.g., JWT, OAuth) replaces them with short-lived tokens.

How Tokens Work

1. User logs in → Server issues a token (e.g., JWT).
2. Token contains:
   • Payload (user ID, expiry time).
   • Signature (verified with server’s secret key).
3. Client sends token with each request (no password needed).

stateDiagram-v2
    [*] --> Login
    Login --> AuthServer: {Send credentials}
    AuthServer --> Token: {Issue JWT}
    Token --> Client: {Store token (localStorage)}
    Client --> API: {Send token in Authorization: Bearer <token>}
    API --> AuthServer: {Verify token}
    AuthServer --> API: {Grant access}
    API --> Client: {Return data}
    Client --> [*]

Real-World Token Use Cases

• Khalti/Daraz: Uses OAuth 2.0 for third-party app logins (e.g., "Login with Google").
• eSewa: JWT tokens for secure API access between banks and eSewa.
• Ncell’s MyNcell App: Refresh tokens to extend session validity.

Advantages:

• Stateless: No server-side session storage.
• Scalable: Tokens can be validated by any server.
• Secure: Short expiry times limit damage from leaks.

Disadvantages:

• Token theft risk: If stolen, attacker gains access until expiry.
• Storage issues: Tokens in localStorage are vulnerable to XSS.

4. Access Rights and Trust Frameworks in Action

Access rights define what a user can do (e.g., read, write, delete). Trust frameworks enforce these rights across systems.

Types of Access Rights

Trust Framework Workflow: eSewa Payment

1. User logs into eSewa (via OAuth token).
2. eSewa verifies user’s digital signature (PKI).
3. Bank checks KYC records (centralized trust).
4. Transaction is logged in blockchain (decentralized trust).
5. Receipt is signed with eSewa’s private key.

erDiagram
    USER ||--o{ TRANSACTION : "makes"
    USER ||--o{ DIGITAL_SIGNATURE : "has"
    BANK ||--o{ TRANSACTION : "processes"
    TRANSACTION }|--|| BLOCKCHAIN : "records"
    eSewa ||--o{ TRANSACTION : "facilitates"
    eSewa ||--|{ DIGITAL_SIGNATURE : "issues"

In the Real World

1. eSewa’s Trust Framework:

   • Uses PKI for digital signatures on transactions.
   • OAuth 2.0 for third-party app integrations (e.g., Daraz payments).
   • Honeypots in test environments to simulate phishing attacks.

2. Ncell’s Security:

   • Kerberos secures internal network access for employees.
   • High-interaction honeypots detect SIM-swapping attacks (where hackers take over phone numbers).

3. Daraz’s Token-Based Auth:

   • JWT tokens replace passwords for API calls (e.g., order tracking).
   • Honeypot servers mimic Daraz’s database to trap credential-stuffing bots.

4. Nepal Rastra Bank (NRB) Compliance:

   • Federated trust between banks for KYC verification.
   • Audit logs stored in tamper-proof ledgers (blockchain).

Exam Tip

This unit is conceptual but heavily diagram-based. Expect:

1. Definitions (e.g., "Define access right"):

   • Access right: A permission granted to a user/process to perform an action (e.g., read/write/execute) on a resource.
   • Trust framework: A system of policies, protocols, and technologies to establish and maintain trust between entities (e.g., PKI + OAuth).

2. Explain with diagrams:

   • Draw a honeypot deployment (low vs. high interaction).
   • Kerberos sequence diagram (must show TGT and service ticket).
   • Trust model (centralized vs. federated).

3. Compare and contrast:

   • Honeypot types (table with pros/cons).
   • Token vs. session-based auth (JWT vs. cookies).

4. Real-world applications:

   • Link eSewa/Khalti to OAuth/PKI.
   • Link NTC/Ncell to Kerberos/honeypots.

Common Pitfalls:

• Forgetting to label diagrams (e.g., "TGT" in Kerberos).
• Confusing symmetric (Kerberos) vs. asymmetric (PKI) crypto.
• Overlooking high-interaction honeypot risks (e.g., "What if the attacker exploits a bug?").

Kerberos ticket flow: TGT → Service Ticket → Access Grant (Image: Jeran Renz, CC BY-SA 4.0, via Wikimedia Commons)

CA → Certificate Issuance → Digital Signature Workflow (Image: Chris 論, CC BY-SA 3.0, via Wikimedia Commons)