Summary of HTB Mumbai Meetup held on 12th September 2026

This blog is a summary of what was discussed and demonstrated at HTB Meetup Mumbai #19 held on 12th September 2026.

The meetup featured two deep-dive sessions focusing on offensive security, low-level architecture, and real-world penetration testing case studies:

1. Session 1: "Signed Does Not Mean Safe: The BYOVD Trust Problem" by Sushant Mane (Founder, The Cyber Veda India)
2. Session 2: "Coffee Shop to Corporate Network: Understanding the Hidden Risks of Connected IoT Devices" by Omkar Mali (Hardware & OT Security Researcher, Former IBM X-Force Red Team Member)

---

Session 1: "Signed Does Not Mean Safe: The BYOVD Trust Problem" by Sushant Mane

The first session focused on modern Windows endpoint security, the mechanisms endpoint detection and response (EDR) solutions use to protect themselves, and how attackers leverage legitimately signed, vulnerable kernel drivers to dismantle these protections from Ring 0.

Fig 1.1: Technical workflow of Session 1 covering Windows Kernel Architecture, EDR defenses, and BYOVD exploitation.

---

Part 1: Operating System Fundamentals & Privilege Boundaries

To understand how security tools defend Windows and why attackers target the kernel, it is necessary to examine how the operating system partitions memory and privilege.

1. User Mode (Ring 3) vs. Kernel Mode (Ring 0)

Modern processor architectures (such as x86/x64) implement hardware privilege rings to enforce execution boundaries:

• User Mode (Ring 3): Standard user applications, background services, and third-party software execute here. In User Mode, every process operates inside its own isolated virtual address space. A user-mode application cannot directly read or write memory belonging to another process or the kernel, nor can it execute privileged CPU instructions. If an application crashes due to an unhandled exception, only that individual process terminates; the underlying operating system remains intact.
• Kernel Mode (Ring 0): The core operating system executive (ntoskrnl.exe), the Hardware Abstraction Layer (HAL), and kernel-mode device drivers execute here. Kernel code runs in a single, shared flat virtual address space with unrestricted access to physical memory, hardware I/O ports, and CPU control registers. An unhandled exception or memory corruption in Ring 0 triggers a system bugcheck (KeBugCheckEx), resulting in a Blue Screen of Death (BSOD).

Fig 1.2: CPU privilege rings. Ring 0 operates with full hardware authority, while Ring 3 enforces process isolation.

2. The Role of Device Drivers

A device driver is a software component that facilitates communication between the Windows Executive and physical hardware (or virtual devices). Because hardware devices require direct memory mapping and interrupt handling, hardware drivers execute in Kernel Mode (Ring 0).

To visualize this, consider an application sending a print job:

1. The application issues a high-level API call.
2. The operating system formats the request and passes it to the printer driver.
3. The printer driver translates the abstract print command into hardware-specific commands understood by the printer's internal controller.

tip

Because drivers reside in Ring 0, any vulnerability inside a driver runs with the full authority of the Windows kernel, completely bypassing user-mode restrictions.

---

Part 2: Windows Defensive Primitives Explained

Security products (Antivirus, EDR, and digital forensics tools) deploy kernel-mode drivers to gain visibility and enforce active defenses. The session examined four fundamental defensive mechanisms:

1. Protected Process Light (PPL)

Windows historically allowed any process running with administrative privileges (SeDebugPrivilege) to inspect, modify, or terminate any other user-mode process. To prevent malware with local administrator rights from tampering with core system components, Microsoft introduced the Protected Process (PP) model in Windows Vista (initially for digital rights management) and expanded it in Windows 8.1 to Protected Process Light (PPL).

PPL creates a protected container around critical services such as lsass.exe (Local Security Authority Subsystem Service) and antimalware processes (like Windows Defender's MsMpEng.exe).

PPL enforces a hierarchical trust model governed by the process signer level:

Level (Decimal)	Signer Value (Hex)	Signer Name	Hierarchy Rank	Target Protected Processes
7	0x07 / 0x82	WinSystem	Highest Authority	Core kernel system components, smss.exe
6	0x06 / 0x72	WinTcb	Trusted Computing Base	csrss.exe, services.exe
5	0x05 / 0x62	Windows	Standard OS Services	wininit.exe, lsaiso.exe
4	0x04 / 0x52	Lsa	Identity & Secrets Target	lsass.exe (Credential storage)
3	0x03 / 0x42	Antimalware	Security Software	AV/EDR Engines (MsMpEng.exe)
2	0x02 / 0x32	CodeGen	Compiler Services	Dynamic code generation tools
1	0x01 / 0x22	Authenticode	Signed Applications	Authenticode-signed 3rd-party software
0	0x00 / 0x00	None	Lowest (Unprotected)	Standard user applications & malware

Fig 1.3: Windows Protected Process Light (PPL) Signer Hierarchy. Lower tiers cannot acquire write/terminate handles to higher tiers.

The protection level is stored inside the kernel's internal process representation structure, EPROCESS, in the PS_PROTECTION field:

typedef struct _PS_PROTECTION {
    union {
        UCHAR Level;
        struct {
            UCHAR Type   : 3; // PS_PROTECTED_TYPE (None=0, ProtectedLight=1, Protected=2)
            UCHAR Audit  : 1; // Audit mode flag
            UCHAR Signer : 4; // PS_PROTECTED_SIGNER (None, Authenticode, Antimalware, Lsa, Windows, WinTcb, etc.)
        } s;
    };
} PS_PROTECTION, *PPS_PROTECTION;

When a process requests a handle to another process via the standard Windows API OpenProcess, the kernel evaluates the caller's protection level against the target:

• A non-PPL process (Level 0) attempting to open a handle to a PPL process (Level 3 or Level 4) with permissions such as PROCESS_TERMINATE, PROCESS_VM_READ, or PROCESS_VM_WRITE will receive an ACCESS_DENIED (error code 5) response, even if the caller is running as NT AUTHORITY\SYSTEM.

2. Kernel Callbacks (The EDR Nervous System)

To detect and intercept threats in real time, EDR drivers register Kernel Callbacks. These routines subscribe to operating system events directly inside the kernel:

Fig 1.4: Kernel Callbacks Model. EDR drivers subscribe to low-level system events to inspect and block malicious operations synchronously.

The primary kernel callback registration APIs include:

• PsSetCreateProcessNotifyRoutineEx:
  • Standard Usage: Allows drivers to receive notifications whenever a process is created or exits.
  • EDR Enforcement: The callback receives a pointer to PS_CREATE_NOTIFY_INFO. If the EDR determines the binary or parent-child relationship is malicious, it sets CreationStatus = STATUS_ACCESS_DENIED. The kernel immediately aborts process creation before the main thread ever executes.
• PsSetCreateThreadNotifyRoutine:
  • Standard Usage: Tracks thread creation across the system.
  • EDR Enforcement: Detects remote thread creation (such as process injection via CreateRemoteThread).
• PsSetLoadImageNotifyRoutine:
  • Standard Usage: Notifies registered drivers when an executable image (EXE, DLL, or driver) is mapped into memory.
  • EDR Enforcement: Scans mapped modules and checks digital signatures before execution starts.
• ObRegisterCallbacks:
  • Standard Usage: Object Manager callback that intercepts handle operations on processes, threads, and desktop objects.
  • EDR Enforcement: When an attacker attempts to open a handle to a security process (OpenProcess), the EDR driver intercepts the pre-operation callback (OB_PRE_OPERATION_CALLBACK) and dynamically strips high-privilege access masks (such as PROCESS_TERMINATE, PROCESS_VM_WRITE, and PROCESS_DUP_HANDLE).
• CmRegisterCallbackEx:
  • Standard Usage: Registers a registry filtering callback.
  • EDR Enforcement: Blocks unauthorized modifications to persistence keys (e.g., Run keys, Services registry hives).

3. Driver Signature Enforcement (DSE)

To prevent attackers from loading unsigned rootkits, 64-bit Windows enforces Driver Signature Enforcement (DSE). Managed by the Code Integrity module (CI.dll), DSE requires all kernel drivers to have a valid digital signature counter-signed by Microsoft before they can be loaded into memory.

DSE state is controlled by global variables inside CI.dll, primarily g_CiEnabled (and g_CiOptions on modern releases). If a driver binary is unsigned or its certificate chain is invalid, NtLoadDriver fails with STATUS_INVALID_IMAGE_HASH.

---

Part 3: The Trust Breakdown & The BYOVD Concept

While DSE ensures that only digitally signed drivers can be loaded, a cryptographic signature validates authorship and integrity, it does not validate code safety.

Fig 1.5: The BYOVD Trust Paradox. Cryptographic validity does not guarantee memory safety or exploit resistance.

What is Bring Your Own Vulnerable Driver (BYOVD)?

BYOVD is an offensive technique in which an attacker with local administrative privileges drops a legitimate, officially signed third-party driver that contains known security vulnerabilities (such as arbitrary memory read/write primitives or unvalidated process control routines) onto the target machine.

Because the driver is properly signed, Windows loads it through standard service mechanisms (sc create / sc start). The attacker then communicates with the driver from user space to exploit its flaws, executing arbitrary logic with Kernel Mode (Ring 0) authority.

Known vulnerable drivers are indexed publicly on repositories like LOLDrivers.io (Living Off The Land Drivers), tracking thousands of drivers capable of bypassing security controls.

---

Part 4: The Communication Mechanism , The IOCTL Interface

To interact with a kernel driver, user-mode software uses the standard Windows Input/Output Control (IOCTL) interface.

Fig 1.6: IOCTL Communication Architecture. User-mode clients issue control codes to kernel driver dispatch handlers via DeviceIoControl.

1. Legitimate API Usage

1. CreateFile:
   • Standard Function: Opens a handle to a file, directory, or device object.
   • Driver Usage: The user-mode client calls CreateFile with a device interface path (e.g., \\\\.\\VulnDriverDevice) to obtain an open handle (HANDLE) to the driver.
2. DeviceIoControl:
   • Standard Function: Sends a control code and data buffers directly to a device driver.
   • Syntax:

     BOOL DeviceIoControl(
       HANDLE       hDevice,
       DWORD        dwIoControlCode,
       LPVOID       lpInBuffer,
       DWORD        nInBufferSize,
       LPVOID       lpOutBuffer,
       DWORD        nOutBufferSize,
       LPDWORD      lpBytesReturned,
       LPOVERLAPPED lpOverlapped
     );

   • Driver Handling: Inside the driver, the I/O Manager wraps this request into an I/O Request Packet (IRP) with major function code IRP_MJ_DEVICE_CONTROL and routes it to the driver's registered dispatch routine.

2. The Vulnerability Mechanism

Vulnerabilities arise when the driver's dispatch routine processes input buffers without validating memory pointers, buffer lengths, or caller authorization:

• Arbitrary Memory Read/Write: The driver accepts raw memory addresses from lpInBuffer and performs direct memory copies (memcpy, memmove) between user space and kernel space without verifying address ranges (e.g., failing to use ProbeForRead / ProbeForWrite).
• Exposed Kernel Functionality: The driver exposes an IOCTL that directly calls privileged kernel routines (such as ZwTerminateProcess, ZwOpenProcess, or physical memory mapping functions) on behalf of any user-mode caller.

---

Part 5: Complete BYOVD Attack Workflow & EDR Killer Mechanics

The session demonstrated the end-to-end execution chain used by real-world threat actors and modern ransomware families (such as BlackCat, AvosLocker, and Akira) to neutralize security controls:

Fig 1.7: End-to-end BYOVD Attack Chain from initial access to kernel-level defense impairment.

Step 1: Establishing Administrative Privileges

Loading a kernel driver requires SeLoadDriverPrivilege (granted to local Administrators and SYSTEM). Once an initial foothold is gained, standard privilege escalation techniques are used to elevate to administrative context.

Step 2: Dropping and Registering the Vulnerable Driver

The attacker writes the signed driver binary (e.g., wsftprm.sys, truesight.sys, or mhyprot2.sys) to disk. Because the driver carries a valid digital certificate, default file scanners do not block it.

The driver is registered and started using the Service Control Manager (sc.exe):

sc create THM_LOVES_TCV binPath= "C:\Users\creep\Desktop\vulndriver.sys" type= kernel
sc start THM_LOVES_TCV

Step 3: Communicating with the Driver

The user-mode exploit loader acquires a handle to the driver:

HANDLE hDriver = CreateFileA(
    "\\\\.\\WSFTPRM",
    GENERIC_READ | GENERIC_WRITE,
    0,
    NULL,
    OPEN_EXISTING,
    FILE_ATTRIBUTE_NORMAL,
    NULL
);

Step 4: Neutralizing EDR Defenses

Attackers employ several methods depending on the vulnerable driver's capabilities:

Method A: Direct Process Termination via Driver Dispatch

In the live demonstration, the speaker leveraged a vulnerable driver (wsftprm.sys, CVE-2023-52271) abused by AV-EDR-Killer:

• Vulnerability Details: Triggered via IOCTL 0x22201C with a 1036-byte buffer. The first 4 bytes contain the target Process ID (PID) as a DWORD.
• Underlying Execution: Upon receiving this IOCTL, the driver executes the kernel API ZwTerminateProcess on the requested PID.
• Because ZwTerminateProcess originates from Ring 0, user-mode PPL protections and ObRegisterCallbacks filters are completely bypassed.
• Target Processes Terminated:
  • MsMpEng.exe (Microsoft Defender core antimalware service)
  • NisSrv.exe (Microsoft Network Realtime Inspection Service)
  • SecurityHealthService.exe (Windows Security Center service)
  • smartscreen.exe (Windows Defender SmartScreen)

[+] Driver initialized successfully!
[+] Driver ready for operation, Handle: 0x8aadcff970
[*] Scanning for target processes...
  -- Found MsMpEng.exe - PID: 2296
[*] Killing MsMpEng.exe ...
[+] IOCTL 0x22201C sent for PID: 2296
  -- Found NisSrv.exe - PID: 4776
[*] Killing NisSrv.exe ...
[+] IOCTL 0x22201C sent for PID: 4776

Method B: PPL Stripping via Direct Kernel Object Manipulation (DKOM)

When using a driver that provides arbitrary read/write primitives (such as the RTCore64 driver utilized in PPLKiller by Mattiwatti):

1. The exploit locates the base address of the kernel (ntoskrnl.exe) and finds the active process list (PsInitialSystemProcess).
2. It walks the ActiveProcessLinks doubly linked list to locate the target EPROCESS structure (e.g., lsass.exe or the EDR process).
3. Using documented struct offsets (cataloged by the Vergilius Project across various Windows build versions), it targets the _PS_PROTECTION byte.
4. PPL Stripping: It writes 0x00 into EPROCESS.Protection.Level, downgrading the process to an unprotected state. Standard tools can then open handles with full access rights.
5. PPL Elevation: Alternatively, the exploit writes 0x72 (WinTcb) into the attacker's own process _PS_PROTECTION field, granting it authority to inspect any other protected process on the machine.

Method C: Blinding Kernel Callbacks

Instead of terminating the EDR process (which might trigger external watchdog alerts), advanced attackers zero out kernel callback arrays:

1. The attacker locates unexported kernel callback arrays such as PspCreateProcessNotifyRoutine, PspCreateThreadNotifyRoutine, and PspLoadImageNotifyRoutine.
2. Each array holds up to 64 callback routine pointers encoded using pointer alignment masks.
3. The exploit locates the entries belonging to the EDR's driver module and writes NULL (or replaces them with pointers to a dummy RET instruction).
4. Result: The EDR user-mode agent continues running normally, reporting a healthy state, while remaining completely blind to newly spawned processes, injected threads, and loaded modules.

---

Part 6: Post-Exploitation & DSE Patching

Once kernel-level control is established and security software is neutralized:

1. LSASS Credential Dumping

With PPL stripped or EDR drivers blinded, tools such as Mimikatz execute unhindered:

mimikatz # privilege::debug
mimikatz # sekurlsa::logonpasswords
mimikatz # coffee

Attackers dump cleartext credentials, NTLM hashes, and Kerberos tickets directly from lsass.exe memory.

2. DSE Patching (The Door to Unsigned Rootkits)

Using the kernel write primitive, tools like DSE-Patcher locate the Code Integrity variable g_CiEnabled (or g_CiOptions) in CI.dll memory:

1. The exploit overwrites g_CiOptions with 0x0 (disabling digital signature checks).
2. The attacker loads custom, unsigned kernel rootkits to achieve persistent, covert Ring 0 control.
3. The exploit restores the original g_CiOptions value to evade periodic integrity validation routines.

---

Part 7: Defensive Countermeasures & Mitigations

Defending against BYOVD requires a defense-in-depth strategy:

1. Microsoft Vulnerable Driver Blocklist & WDAC:
   • Enforce Windows Defender Application Control (WDAC) policies configured with Microsoft's recommended driver block rules.
   • Enable Hypervisor-Protected Code Integrity (HVCI) / Memory Integrity to enforce driver blocklists at the hypervisor layer.
2. Logic-Based YARA Rules:
   • Rather than matching volatile file hashes (which attackers modify by altering non-functional metadata or padding), YARA rules should match specific IOCTL dispatch opcodes and unique code patterns of known-vulnerable drivers.
3. Kernel Telemetry & Integrity Watchdogs:
   • Implement EDR self-monitoring that periodically verifies the integrity of registered kernel callbacks and driver service states.
4. Credential Guard & Zero Trust:
   • Enable Windows Defender Credential Guard, which isolates LSASS secrets inside a Virtual Secure Mode (VSM) enclave powered by the Hyper-V hypervisor, preventing even Ring 0 kernel code from accessing plaintext keys.

---

Session 2: "Coffee Shop to Corporate Network: Understanding the Hidden Risks of Connected IoT Devices" by Omkar Mali

The second session presented an end-to-end red team case study demonstrating how a seemingly benign, untrusted smart device, a smart refrigerator in a corporate café, can be exploited to compromise an enterprise active directory environment, corporate email systems, VPN gateways, and internal video surveillance infrastructure.

Fig 2.1: Technical workflow of Session 2 covering the Coffee Shop to Corporate Network Attack Path.

---

Part 1: The Expanding IoT & Automotive Attack Surface

The speaker introduced the concept that modern IoT devices are full-fledged networked computers embedded with sensors, proprietary firmware, and continuous cloud connectivity.

To contextualize the severity of IoT and connected embedded architectures, the speaker highlighted the Connected Vehicle Attack Surface, referencing real-world research against modern autonomous and connected vehicles (such as the KIA vehicle vulnerability). In that scenario, security researchers demonstrated that knowing only a vehicle's public Vehicle Identification Number (VIN) allowed attackers to query backend telematics web APIs, remotely track live GPS coordinates, unlock vehicle doors, honk horns, and start engines over the internet without requiring physical proximity or access to the key fob.

The same architectural flaws observed in automotive ecosystems, weak API authentication, hardcoded developer credentials, and lack of firmware validation, exist in everyday smart appliances.

---

Part 2: The Coffee Shop Attack Scenario & Physical UI Escape

note

Engagement Scenario & Constraints:

Environment: An operator is seated in a ground-floor coffee shop/café shared with upper-floor corporate employees as an auxiliary break room.

Hardware Footprint: Minimalist setup consisting solely of a standard laptop, no Software-Defined Radios (SDRs), high-gain directional antennas, or physical network taps.

1. Physical Footprint & UI Kiosk Escape

To identify attack vectors without raising suspicion from café staff or patrons:

• The operator approached the smart refrigerator under the guise of dispensing water from the integrated panel.
• Kiosk Mode Bypass: Modern interactive appliance touchscreens run locked-down Android or embedded Linux user interfaces. The operator performed a multi-finger long-press gesture (3-finger or 4-finger hold) on the display.
• This interaction triggered the underlying operating system's engineering menu, escaping the kiosk environment into standard system settings.
• Data Harvested from Screen: Internal IP address, subnet mask, default gateway, device model number, and the local Wi-Fi configuration.

---

Part 3: OSINT, AI-Assisted Translation & Default Developer Credentials

1. Vendor Reconnaissance

• Inspecting the device model confirmed the manufacturer was headquartered in China.
• Standard search queries on English domains (.com) yielded basic promotional brochures and user manuals with no administrative details.

2. AI-Assisted Foreign Language Intelligence

• The operator pivoted searches to Chinese domains (.cn), searching for developer documentation, engineering guides, and test specifications.
• To analyze technical Chinese documentation, the operator utilized language models (Claude and DeepSeek) to translate engineering schematics and developer references.
• By translating technical terms such as "Default SSID" and "Factory Test Configuration" into Chinese, the operator located an engineering manual containing default Wi-Fi access point patterns:
  • Credential Pattern: <ModelName>@<LaunchYear>
• Using this pattern, the operator successfully authenticated to the refrigerator's broadcasted Wi-Fi access point.

---

Part 4: Device Compromise & Unauthenticated Web Interfaces

Once connected to the appliance's local network:

• An Nmap port scan revealed open services:
  • Port 22/tcp (SSH)
  • Port 80/tcp / 8080/tcp (HTTP Management Web Interface)
• Navigating to http://<Refrigerator_IP>:8080/ redirected directly to the internal administrative dashboard without requesting authentication (index.html).
• Management Capabilities:
  • Full temperature control and compressor power toggles (Denial of Service).
  • Unauthenticated Firmware Update / Upload endpoint.
• Firmware Flashing Analysis: Post-assessment analysis revealed that the device accepted unsigned firmware images over USB or HTTP without cryptographic signature checks, granting unrestricted remote code execution (RCE) and low-level hardware debugging toolkit access (UART/JTAG).

---

Part 5: Pivoting to the Corporate Network (The Missing VLAN)

Fig 2.2: The Missing VLAN Architecture. The smart refrigerator bridged the untrusted physical café directly into the internal corporate network.

1. Architectural Failure: Lack of Network Segmentation

The café was located directly beneath a corporate office and served as an employee break room. To avoid Network Operations Center (NOC) overhead, device registration costs, and separate VLAN provisioning, network administrators had connected the smart refrigerator directly to the primary corporate subnet.

2. Subnet Discovery

Using tools such as nmap and Angry IP Scanner, the operator enumerated the local /24 subnet:

• Discovered Assets:
  • 30+ Enterprise Workstations: Active Directory domain-joined machines exposing NetBIOS/SMB names indicating employee workstations and departmental groups.
  • 5 Enterprise Network Printers: Exposing unauthenticated management dashboards with bulk print capabilities (uploading arbitrary documents or initiating denial-of-service paper feed loops).

---

Part 6: External OSINT, Breached Credential Mining & Account Validation

Having identified the target corporate domain name from workstation NetBIOS responses, the operator initiated external reconnaissance:

1. Email Harvesting via Phonebook.cz

• Searched the target corporate domain on Phonebook.cz (which indexes billions of public breach records, URLs, and email addresses).
• Retrieved dozens of corporate email addresses belonging to active employees.

2. Cleartext Password Mining via DeHashed

• The operator leveraged the DeHashed database via an automated Python wrapper (dehashed.py) and Leak-Lookup to cross-reference the harvested email list against historical public breaches.
• Findings: Multiple cleartext passwords exposed from third-party non-work services (e.g., flight booking websites, hotel loyalty rewards, and personal accounts where employees registered using their corporate email addresses).
• Password Patterns: Predictable enterprise structures (e.g., Company@2026!, Google@2026!, Summer2026#) rotated quarterly.
• Deduplicating and filtering yielded 30 unique employee email addresses and 25 candidate passwords.

3. Username Validation & Domain Enumeration

To avoid triggering account lockouts by blindly spraying unverified users:

• The operator used msmailprobe and Invoke-UsernameHarvestOWA / TraverseSpray against Microsoft 365 / Exchange Web Services (EWS) endpoints.
• By analyzing server timing responses and metadata validation, the operator confirmed 6 active corporate accounts associated with the target domain.

# Validating harvested accounts against Exchange / OWA endpoints without triggering lockouts
Invoke-UsernameHarvestOWA -ExchHostname mail.<target_domain>.com -UserList .\users.txt -Threads 3 -OutFile validated.users.txt

---

Part 7: Email Account Takeover & Password Spraying

With 6 validated usernames and candidate passwords:

• The operator executed a slow password spray against the Outlook Web Access (OWA) portal using Invoke-PasswordSprayOWA:
  • Enforced a 10-minute sleep interval between attempts with randomized jitter to stay beneath account lockout thresholds.
• Success: Authenticated successfully into an active employee mailbox.

note

Target Authentication Status & Security Gaps:

Target Environment: Microsoft 365 Outlook Web Access (https://mail.<target_domain>.com/owa/)
Authentication Status: Successful takeover of employee domain account.
Critical Vulnerability 1: No Multi-Factor Authentication (MFA) was enforced for this account.
Critical Vulnerability 2: Account status was marked "Out of Office" (OOO / Vacation), minimizing risk of concurrent session alerts.

Stealthy Email Reconnaissance

To avoid triggering endpoint DLP or SOC file-download alerts:

• The operator reviewed messages exclusively through OWA's web preview mode.
• The mailbox contained internal communications, client spreadsheets, and technical onboarding messages.

---

Part 8: Corporate VPN Gateway Compromise

Inside the compromised mailbox, the operator discovered a recent email sent from an encrypted ProtonMail address containing VPN onboarding credentials:

• VPN Password Reset Interception:
  1. The operator navigated to the corporate Palo Alto GlobalProtect VPN portal.
  2. Initiated a "Forgot Password" self-service reset for the compromised employee email.
  3. The time-sensitive One-Time Passcode (OTP) was delivered directly into the compromised Outlook inbox.
  4. The operator completed verification, established a new VPN password, and deleted the password-reset notification email to maintain persistence.
• Internal Network Access: Authenticated to the corporate network through the GlobalProtect VPN client.

---

Part 9: Surveillance Infrastructure Discovery & Critical Intelligence

Operating from inside the corporate internal network via the VPN tunnel, the operator conducted subnet discovery:

1. Video Management System (VMS) Access

• Located exposed internal surveillance servers running Milestone / Camera XP IP Camera systems with default/weak credentials.
• Gained access to live video surveillance feeds across multiple operational zones:
  • Main floor cameras
  • VIP gaming areas (Blackjack, High-Limit tables, Roulette)

2. Underground Operations Discovered

• Deeper reconnaissance of connected internal management applications uncovered live streaming of illicit Russian Roulette competitions (displaying prize boards structured at $1M,$20M, and $60M tiers).
• Internal database records revealed tracking telemetry for physical shock collars, matching profiles of individuals cataloged in public missing persons databases.
• Exposed administrative documents recorded falsified hospital records and unauthorized post-mortem organ trade logs.
• The operator immediately halted assessment activities, documented forensic artifacts, and escalated the findings to authorized legal and investigative authorities.

---

Part 10: Threat Modeling, OPSEC & Defensive Lessons

1. Threat Modeling with the STRIDE Framework

The session highlighted that structured threat modeling must always precede technical testing:

STRIDE Category	Description	IoT / Refrigerator Scenario Mapping
Spoofing	Impersonating an identity or device	Connecting to Wi-Fi using hardcoded developer credentials; MAC spoofing
Tampering	Modifying data in transit or memory	Unauthenticated firmware flashing; altering temperature settings
Repudiation	Denying performed actions	Lack of audit logging on embedded appliance endpoints
Information Disclosure	Exposing sensitive data	Leaking corporate subnets; cleartext password exposure via DeHashed
Denial of Service	Disrupting service availability	Shutting down refrigerator compressors; printer paper flood attacks
Elevation of Privilege	Gaining unauthorized access	Escaping touch panel kiosk mode; resetting corporate VPN passwords

Fig 2.3: The CIA Triad Hierarchy. Integrity is the foundational pillar; if Integrity collapses, Confidentiality and Availability fail.

2. Operational Security (OPSEC) Pitfalls

• Browser Maximization Fingerprinting: Maximizing Tor Browser or privacy browsers leaks exact desktop display dimensions and monitor aspect ratios, enabling canvas and viewport fingerprinting across web sessions.
• ISP-Level Monitoring: Tor traffic entry and exit nodes remain visible to Internet Service Providers without dedicated encrypted encapsulation.

3. Core Defensive Takeaways

• Network Micro-Segmentation: Isolate all IoT, smart appliances, building controls, and guest networks into dedicated VLANs with zero routing to corporate Active Directory environments.
• Mandatory Phishing-Resistant MFA: Enforce hardware-token (FIDO2/WebAuthn) or authenticator-based MFA across all external identity providers (OWA, M365, VPNs).
• Disable Default Services & Interfaces: Deactivate unnecessary Wi-Fi access points, Bluetooth discovery, and unauthenticated web interfaces on embedded hardware.
• Credential Exposure Monitoring: Regularly monitor breach databases for compromised corporate email credentials and enforce strict credential hygiene.

---

References and Further Reading

Windows Kernel & BYOVD Security (Session 1)

• LOLDrivers.io , Living Off The Land Drivers curated database of vulnerable, signed Windows drivers used in real-world attacks.
• Vergilius Project , Comprehensive index of undocumented Windows kernel structures (_EPROCESS, _ETHREAD, _PS_PROTECTION) across OS versions.
• Microsoft Recommended Driver Block Rules , Official WDAC and HVCI driver blocklist guidelines.
• TrueSight Killer (GitHub) , Proof-of-concept tool demonstrating EDR termination via vulnerable driver IOCTL abuse.
• AV-EDR-Killer (GitHub) , Open-source BYOVD implementation leveraging wsftprm.sys (CVE-2023-52271).
• PPLKiller by Mattiwatti (GitHub) , Tool demonstrating PPL stripping and DKOM manipulation via vulnerable signed drivers.
• DSE Patcher (GitHub) , Demonstrates disabling Driver Signature Enforcement via kernel write primitives.
• Protected Processes & PPL Architecture (Alex Ionescu) , Fundamental research on Windows Protected Process Light internals.
• Windows Kernel Programming by Pavel Yosifovich , Reference book for Windows kernel architecture, driver development, and IOCTL dispatching.
• HEVD Windows Kernel Exploitation: Stack Overflow (Sushant Mane) , Practical analysis of stack-overflow exploitation in the HackSys Extreme Vulnerable Driver.
• Kernel Shield: Reversing the NSEckrnl Malops.io Rootkit Driver (Sushant Mane) , Reverse-engineering research on the NSEckrnl rootkit driver and kernel-level defensive techniques.

IoT Security, Threat Modeling & OSINT (Session 2)

• OWASP Internet of Things (IoT) Top 10 , Standard security awareness documentation covering weak passwords, insecure interfaces, and lack of firmware validation.
• Phonebook.cz , Open-source intelligence tool for domain and email enumeration.
• DeHashed & Leak-Lookup , Public breach search engines for credential exposure auditing.
• Microsoft STRIDE Threat Model , Structural framework for categorizing threats (Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege).
• Automotive Security Research: Remote Vehicle Takeover , Detailed analysis of connected vehicle API vulnerabilities allowing remote tracking and control via VIN numbers.
• TraverseSpray & msmailprobe (GitHub) , Tools for enumerating Microsoft 365 Exchange endpoints and performing password spraying.