[{"content":"Executive Summary This report documents an investigation into a localized phishing campaign on the Threads platform. The threat actor used a fake Touch \u0026rsquo;n Go \u0026ldquo;Money Packet\u0026rdquo; QR code to lure victims to a newly established, Cloudflare-proxied credential-harvesting domain. The investigation extracted the payload, mapped the hidden infrastructure, and produced actionable Indicators of Compromise (IOCs) with an exceptionally low initial detection rate.\nTechnical Analysis 1. Initial Discovery \u0026amp; Social Engineering Tactic The investigation began with a suspicious reply under a viral, high-traffic post on Threads.\nThreat Actor Modus Operandi:\nComment Hijacking: The attacker targeted a high-visibility post to maximize the number of potential victims. Burner Account: A newly created account with 0 followers deployed the payload, a common indicator of the automated or burner accounts used in phishing campaigns. Baiting (Digital Cash Gift): The attacker uploaded an image disguised as a Touch \u0026rsquo;n Go \u0026ldquo;Money Packet\u0026rdquo;. By mimicking the genuine acts of charity (sedekah) common on local social media, the attacker exploited victims\u0026rsquo; trust and enticed them to scan the malicious QR code. Figure 1: Analyst Note: The threat actor\u0026rsquo;s profile picture is redacted to protect the likely innocent individual whose image was scraped to create this burner account.\n2. Evidence Acquisition \u0026amp; Secure Handling The initial evidence consisted of raw screenshots captured on a mobile device during discovery on Threads.\nTo maintain strict Operational Security (OpSec) and prevent accidental execution or network leakage on the primary device, the screenshots (qrfraud.png) were transferred directly to the CSI Linux digital forensics environment via an isolated local FTP server.\nThis established a clean chain of custody and confined the investigation to a controlled virtual machine before any extraction tools were applied.\n3. Methodology \u0026amp; Operational Security (OpSec) Before initiating passive reconnaissance against the malicious infrastructure, the CSI Linux environment was verified to route all traffic through the Tor network.\nAn initial IP check against a standard geolocation service (ipinfo.io) returned a 403 Forbidden error. This signals OpSec success: the server\u0026rsquo;s Web Application Firewall (WAF) detected and blocked a connection originating from a known Tor exit node.\n❯ curl ipinfo.io \u0026lt;html\u0026gt;\u0026lt;head\u0026gt; \u0026lt;title\u0026gt;403 Forbidden\u0026lt;/title\u0026gt; [...snip...] \u0026lt;h1\u0026gt;Error: Forbidden\u0026lt;/h1\u0026gt; \u0026lt;h2\u0026gt;Your client does not have permission to get URL \u0026lt;code\u0026gt;/\u0026lt;/code\u0026gt; from this server.\u0026lt;/h2\u0026gt; To confirm Tor routing without relying on third-party services that blacklist Tor nodes, the official Tor Project API was used:\n❯ curl -s https://check.torproject.org/api/ip {\u0026#34;IsTor\u0026#34;:true,\u0026#34;IP\u0026#34;:\u0026#34;[REDACTED]\u0026#34;} 4. Payload Extraction (QR Decoding) To analyze the malicious QR code safely, without risking accidental execution or triggering tracking mechanisms, extraction was performed strictly offline within the isolated CSI Linux environment.\nThe zbarimg command-line utility decoded the embedded payload from the evidence file.\n❯ zbarimg qrfraud.png QR-Code:[https://tng.register-lk1.top/Rayamacam2.my2/](https://tng.register-lk1.top/Rayamacam2.my2/) scanned 1 barcode symbols from 1 images in 0.08 seconds Analyst Finding: The extraction decoded a malicious URL pointing to a suspicious subdomain (tng.register-lk1.top). The URI path /Rayamacam2.my2/ correlates directly with the \u0026ldquo;Duit Raya/Sedekah\u0026rdquo; bait used on Threads. The threat actor crafted the URL to spoof Touch \u0026rsquo;n Go (TNG) branding and match the campaign\u0026rsquo;s theme.\n5. DNS Resolution \u0026amp; Infrastructure Masking A standard DNS query against the malicious subdomain identified its hosting infrastructure.\n❯ nslookup tng.register-lk1.top Server: 127.0.0.53 Address: 127.0.0.53#53 Non-authoritative answer: Name: tng.register-lk1.top Address: 104.21.28.155 Name: tng.register-lk1.top Address: 2606:4700:3034::ac43:aae7 Analyst Finding: The nslookup results show the subdomain resolving to 104.21.28.155, an IP address assigned to Cloudflare\u0026rsquo;s Content Delivery Network (CDN) and Web Application Firewall (WAF).\nThis confirms the threat actor is using Cloudflare\u0026rsquo;s reverse proxy to mask their Origin Server IP. Any direct infrastructure scan (such as an Nmap port scan) against this IP would reach only Cloudflare\u0026rsquo;s edge servers, not the attacker\u0026rsquo;s actual hosting infrastructure.\n6. OSINT \u0026amp; Threat Intelligence Aggregation To analyze the domain without interacting directly with the live phishing site, passive OSINT queries were run through industry-standard threat intelligence platforms.\nDocumenting findings as structured text rather than screenshots keeps the Indicators of Compromise (IOCs) easy to extract for threat hunting.\nA. VirusTotal Analysis The exact payload URL (https://tng.register-lk1.top/Rayamacam2.my2/) was queried for existing vendor flags.\nDetection Ratio: 1/92 security vendors flagged the URL as malicious. Flagging Vendor: ESET identified the URL as \u0026ldquo;Phishing\u0026rdquo;. Analysis Date: 2026-10-05 10:24:31 UTC. Analyst Note (Low Detection Rate): The 1/92 detection rate strongly indicates a newly deployed, potentially zero-day phishing campaign. Most legacy signature-based scanners have not yet blacklisted this URL, making the threat highly elusive to standard endpoint protection. B. URLScan.io Sandbox Execution URLScan.io safely executed a remote HTTP request and captured the web server\u0026rsquo;s response and DOM structure.\nTarget: https://tng.register-lk1.top/Rayamacam2.my2/ Submission Date: October 5th 2026, 10:24:13 am UTC Primary IP: 172.67.170.231 (CLOUDFLARENET) DNS A Record: 104.21.28.155 (CLOUDFLARENET) Page Title: \u0026ldquo;A surprise Money Packet for you!\u0026rdquo; Detected Technologies: cdnjs, Font Awesome, jQuery, jsDelivr TLS Certificate: Issued by WE1 on October 2nd 2026. Valid for 3 months. Summary: The sandbox loaded the phishing landing page. Its title (\u0026ldquo;A surprise Money Packet for you!\u0026rdquo;) correlates directly with the \u0026ldquo;Duit Raya/Sedekah\u0026rdquo; bait. The recent TLS certificate issuance (Oct 2, 2026) further supports the hypothesis that this is newly created infrastructure built for a short-term campaign. Figure 2: Automated sandbox execution rendering the deceptive Touch \u0026rsquo;n Go phishing interface.\nC. DNSDumpster (Historical DNS Reconnaissance) The root domain (register-lk1.top) was analyzed for Origin IP leaks and misconfigured DNS records (such as MX or TXT records) that bypass the Cloudflare proxy.\nNameservers (NS): The domain delegates DNS resolution exclusively to Cloudflare\u0026rsquo;s infrastructure (jaxson.ns.cloudflare.com and candy.ns.cloudflare.com). Finding: The threat actor maintained strict OpSec in their DNS configuration. The mapping graph shows no historical Origin IP leaks, no exposed MX records, and no direct A records bypassing the CDN. Evidence Handling: The raw DNS reconnaissance data was exported as an XLSX file (register-lk1.top-eb89694b-8aa9-494c-8ceb-d2c1ee5a43f0.xlsx) and stored with the visual mapping graphs in the local investigation vault. Figure 3: DNSDumpster text data records showing the Cloudflare proxy infrastructure configuration.\nFigure 4: Visual DNS mapping graph generated by DNSDumpster confirming no historical origin IP leaks.\n7. Conclusion \u0026amp; Indicators of Compromise (IOCs) Investigation Summary: The investigation unmasked a localized phishing campaign operating on Threads. The threat actor used a burner account to distribute a malicious QR code disguised as a Touch \u0026rsquo;n Go \u0026ldquo;Money Packet\u0026rdquo;. The embedded payload directs victims to a newly established, Cloudflare-proxied domain designed to harvest user credentials and eWallet data. The exceedingly low detection rate (1/92 on VirusTotal) indicates an active, rapid-deployment campaign.\nIndicators of Compromise (IOCs): To assist network defenders and SOC teams, the following IOCs were extracted from this investigation:\nType Indicator Description URL https://tng.register-lk1.top/Rayamacam2.my2/ Primary phishing payload embedded in QR code Domain tng.register-lk1.top Malicious subdomain hosting the fake TNG gateway Root Domain register-lk1.top Parent domain (suspected malicious infrastructure) IP Address 104.21.28.155 Cloudflare Proxy IP (CDN/WAF) IP Address 172.67.170.231 Cloudflare Proxy IP (CDN/WAF) Social Engineering \u0026ldquo;A surprise Money Packet for you!\u0026rdquo; HTML Page Title used as bait ","permalink":"https://thenickvendetta.pages.dev/writeups/tng-qr-phishing-analysis/","summary":"\u003ch2 id=\"executive-summary\"\u003eExecutive Summary\u003c/h2\u003e\n\u003cp\u003eThis report documents an investigation into a localized phishing campaign on the Threads platform. The threat actor used a fake Touch \u0026rsquo;n Go \u0026ldquo;Money Packet\u0026rdquo; QR code to lure victims to a newly established, Cloudflare-proxied credential-harvesting domain. The investigation extracted the payload, mapped the hidden infrastructure, and produced actionable Indicators of Compromise (IOCs) with an exceptionally low initial detection rate.\u003c/p\u003e\n\u003chr\u003e\n\u003ch2 id=\"technical-analysis\"\u003eTechnical Analysis\u003c/h2\u003e\n\u003ch3 id=\"1-initial-discovery--social-engineering-tactic\"\u003e1. Initial Discovery \u0026amp; Social Engineering Tactic\u003c/h3\u003e\n\u003cp\u003eThe investigation began with a suspicious reply under a viral, high-traffic post on Threads.\u003c/p\u003e","title":"Threat Investigation: Touch 'n Go QR Phishing Campaign"},{"content":"Executive Summary During my industrial training (internship) at the university\u0026rsquo;s central ICT department, my supervisor assigned me the full deployment lifecycle of a dedicated, campus-wide Moodle Learning Management System (LMS). The deployment centralizes academic resources across multiple faculties and replaces legacy, fragmented services.\nRather than using virtualized resource slices, I architected and deployed the system directly on bare-metal enterprise rack hardware: a Dell PowerEdge R420. The entire implementation ran through the headless Linux CLI and was secured with industry-standard hardening, least-privilege access controls, and automated operational pipelines.\n1. Hardware Provisioning \u0026amp; Physical Telemetry Enterprise Server Baseline The platform was provisioned on dedicated rack-mounted enterprise hardware:\nServer Chassis: Dell PowerEdge R420 (Dual-socket Intel Xeon architecture, Redundant Power Supplies) Storage Subsystem: Dual 10,000 RPM enterprise SAS drives (Toshiba AL13SEB300, 300GB each) driven by an integrated PERC hardware RAID controller Memory Architecture: 16GB DDR3 ECC Registered Memory +--------------------------------------------------------------+ | Dell PowerEdge R420 | | [Dual Intel Xeon] [16GB ECC RAM] [Redundant PSUs] | +--------------------------------------------------------------+ | | v v +------------------+ +--------------------+ | PERC Controller | | iDRAC Out-of- | | (SAS RAID 1) | | Band Management | +------------------+ +--------------------+ | v +--------------------------------------------------------------+ | Logical Volume Manager (LVM) | | ├── /dev/sda2: /boot (2 GB) | | └── /dev/sda3: / (100 GB Root System) | +--------------------------------------------------------------+ Pre-Installation Firmware \u0026amp; Drive Health Triage Before OS installation, I used iDRAC out-of-band management to verify hardware event logs (SEL), power supply redundancy, and thermal thresholds.\nDrive integrity was audited with smartctl (smartmontools suite) over the SAS transport interface:\n# Deep SAS SMART health inspection sudo smartctl -a /dev/sda SMART Health Status: OK (0 uncorrected read/write errors) Operating Temperature: Stable at 35°C Background Diagnostic: Extended self-test completed with zero defect list growth. Volumes were partitioned with Linux Logical Volume Manager (LVM), separating the root filesystem (/) from boot so storage can expand dynamically without downtime.\n2. Base Operating System Hardening \u0026amp; Networking The server runs a minimal Ubuntu Server LTS installation with no graphical desktop environment, reserving compute cycles for database transactions and web worker threads.\nAdministrative Access Hardening Remote administration uses SSH key-pair authentication only, which removes password brute-force exposure:\n# Generate high-entropy Ed25519 key on admin workstation ssh-keygen -t ed25519 -C \u0026#34;admin-infra\u0026#34; # Install public key and restrict daemon ssh-copy-id -i ~/.ssh/id_ed25519.pub -p \u0026lt;SSH_PORT\u0026gt; \u0026lt;SSH_USER\u0026gt;@192.0.2.10 In /etc/ssh/sshd_config, password authentication and root login are disabled:\nPermitRootLogin no PasswordAuthentication no X11Forwarding no MaxAuthTries 3 Network Topology \u0026amp; Static Addressing Netplan (/etc/netplan/00-installer-config.yaml) provides static addressing for deterministic DNS resolution and consistent firewall pass-through:\nnetwork: version: 2 ethernets: eno1: addresses: - 192.0.2.10/24 routes: - to: default via: 192.0.2.1 nameservers: addresses: - 8.8.8.8 - 1.1.1.1 Firewall Architecture (UFW) The Uncomplicated Firewall (UFW) enforces a strict default-deny perimeter policy:\nsudo ufw default deny incoming sudo ufw default allow outgoing sudo ufw allow \u0026lt;SSH_PORT\u0026gt;/tcp comment \u0026#39;Hardened SSH Port\u0026#39; sudo ufw allow 80/tcp comment \u0026#39;HTTP Web Traffic\u0026#39; sudo ufw allow 443/tcp comment \u0026#39;HTTPS Encrypted\u0026#39; sudo ufw enable 3. LAMP Stack Architecture \u0026amp; Performance Tuning The application stack consists of Apache 2.4, MariaDB 10.x, and PHP 8.x.\n[ Client HTTPS Requests / Web Browsers ] | v +---------------------------------------------------+ | UFW Perimeter Firewall | | (Allow: 80, 443, 2222 | Deny All) | +---------------------------------------------------+ | v +---------------------------------------------------+ | Apache 2.4 | | (VirtualHost /var/www/html/moodle) | | - mod_rewrite (Clean REST URLs) | | - mod_headers (HTTP Security Headers) | +---------------------------------------------------+ | v +---------------------------------------------------+ | PHP 8.x Engine | | (Tuned: 512M Memory | 200M Upload Payload) | +---------------------------------------------------+ | | v v +-----------------------+ +-----------------------+ | MariaDB | | /var/moodledata | | (utf8mb4_unicode) | | (External Storage | | | 400+ Tables | | Isolated Root) | +-----------------------+ +-----------------------+ Database Layer Provisioning MariaDB was configured with utf8mb4 encoding to support full multilingual indexing and emoji rendering in course communications:\nCREATE DATABASE moodle DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; CREATE USER \u0026#39;moodle_admin\u0026#39;@\u0026#39;localhost\u0026#39; IDENTIFIED BY \u0026#39;\u0026lt;DB_PASSWORD\u0026gt;\u0026#39;; GRANT ALL PRIVILEGES ON moodle.* TO \u0026#39;moodle_admin\u0026#39;@\u0026#39;localhost\u0026#39;; FLUSH PRIVILEGES; PHP Runtime Optimization Default PHP parameters routinely fail under concurrent classroom uploads and background cron executions. The php.ini runtime configuration was tuned for high-concurrency academic workloads:\nDirective Factory Default Tuned Value Engineering Rationale memory_limit 128M 512M Prevents Out-Of-Memory exhaustion during large course backup restorations. upload_max_filesize 2M 200M Accommodates large engineering CAD, ZIP, and slide assignments. post_max_size 8M 200M Matches POST buffer capacity with multi-file form uploads. max_execution_time 30 300 Eliminates script timeout aborts during heavy gradebook report calculations. max_input_vars 1000 5000 Prevents payload truncation on complex grading forms and large quizzes. 4. Application Deployment \u0026amp; Filesystem Isolation The stable production branch of Moodle was cloned directly into the document root with Git:\nsudo git clone -b MOODLE_405_STABLE https://github.com/moodle/moodle.git /var/www/html/moodle Filesystem Security \u0026amp; Path Isolation Following web application security standards, user uploads, dynamic sessions, and caches were isolated entirely outside the exposed web root:\nPublic Web Root: /var/www/html/moodle (Permissions: 755, owned by www-data:www-data) Private Dynamic Data Store: /var/moodledata (Permissions: 770, strictly owned by www-data:www-data) Keeping moodledata outside the document root ensures that uploaded files, whether student assignments or malicious payloads, can never be executed directly through an HTTP request URL.\nReproducible CLI Installation Instead of the stateful browser-based wizard, I ran the installation through Moodle\u0026rsquo;s native administrative CLI:\nsudo -u www-data /usr/bin/php /var/www/html/moodle/admin/cli/install.php \\ --lang=en \\ --wwwroot=https://lms.example.com \\ --dataroot=/var/moodledata \\ --dbtype=mariadb \\ --dbhost=localhost \\ --dbname=moodle \\ --dbuser=moodle_admin \\ --dbpass=\u0026#39;\u0026lt;DB_PASSWORD\u0026gt;\u0026#39; \\ --fullname=\u0026#34;Institutional LMS Portal\u0026#34; \\ --shortname=\u0026#34;LMS\u0026#34; \\ --adminuser=\u0026#39;\u0026lt;ADMIN_USER\u0026gt;\u0026#39; \\ --adminpass=\u0026#39;\u0026lt;ADMIN_PASSWORD\u0026gt;\u0026#39; \\ --non-interactive \\ --agree-license 5. Automation, Maintenance \u0026amp; Disaster Recovery Asynchronous Task Execution (System Cron) Moodle needs continuous background processing for gradebook recalculations, email dispatches, and course backups. I delegated this work to the Linux system cron daemon instead of web requests:\n# Append to www-data crontab sudo crontab -u www-data -e # Run maintenance runner every minute * * * * * /usr/bin/php /var/www/html/moodle/admin/cli/cron.php \u0026gt;/dev/null 2\u0026gt;\u0026amp;1 Database Backup Pipeline with Retention To support business continuity, an automated shell script creates timestamped database exports and purges those older than 14 days on a rolling basis. Database credentials are read from a root-owned option file (mode 600) rather than passed on the command line, so they never appear in the process list or shell history:\n#!/bin/bash umask 077 BACKUP_DIR=\u0026#34;/var/backups/moodle-db\u0026#34; TIMESTAMP=$(date +\u0026#34;%F_%H-%M-%S\u0026#34;) mkdir -p \u0026#34;$BACKUP_DIR\u0026#34; # Generate compressed logical dump (credentials supplied via protected option file) mysqldump --defaults-extra-file=/etc/moodle-backup/db.cnf moodle | gzip \u0026gt; \u0026#34;$BACKUP_DIR/moodle_db_$TIMESTAMP.sql.gz\u0026#34; # Enforce 14-day retention cycle find \u0026#34;$BACKUP_DIR\u0026#34; -type f -name \u0026#34;*.sql.gz\u0026#34; -mtime +14 -delete A dedicated logrotate policy in /etc/logrotate.d/apache2 rotates access and error logs daily with gzip compression to control log growth.\n6. Functional Verification, Performance Benchmarking \u0026amp; Auditing Concurrency Stress Testing (ApacheBench) To validate stability under peak login spikes, I ran synthetic load tests with ApacheBench (ab): 100 requests at a concurrency level of 10:\nServer Software: Apache/2.4.x Server Port: 80 Document Path: / Document Length: 1484 bytes Concurrency Level: 10 Time taken for tests: 0.132 seconds Complete requests: 100 Failed requests: 0 Total transferred: 173700 bytes HTML transferred: 148400 bytes Requests per second: 759.51 [#/sec] (mean) Time per request: 13.166 [ms] (mean) Time per request: 1.317 [ms] (mean, across all concurrent requests) Transfer rate: 1288.35 [Kbytes/sec] received Connection Times (ms) min mean[+/-sd] median max Connect: 0 0 0.2 0 1 Processing: 5 12 3.3 12 20 Waiting: 5 11 3.1 11 20 Total: 6 12 3.3 12 20 Zero Failed Transactions: All concurrent requests completed successfully. Sub-14ms Latency: Mean latency per request was 13.16 ms, well within institutional SLA thresholds. High Transaction Velocity: Achieved ~760 requests per second on bare-metal hardware. Cross-VLAN Routing \u0026amp; Latency Verification ICMP echo tests and hop-trace diagnostics confirmed Layer-3 reachability across distributed campus subnets:\nC:\\Users\\\u0026lt;user\u0026gt;\u0026gt;ping 192.0.2.10 Pinging 192.0.2.10 with 32 bytes of data: Reply from 192.0.2.10: bytes=32 time=5ms TTL=62 Reply from 192.0.2.10: bytes=32 time=5ms TTL=62 Reply from 192.0.2.10: bytes=32 time=7ms TTL=62 Reply from 192.0.2.10: bytes=32 time=5ms TTL=62 Ping statistics for 192.0.2.10: Packets: Sent = 4, Received = 4, Lost = 0 (0% loss), Approximate round trip times in milli-seconds: Minimum = 5ms, Maximum = 7ms, Average = 5ms Post-Deployment Verification Checklist Operational Component Verification Command / Target Success Criteria Status Web Service Connectivity curl -I http://localhost HTTP 200 OK via Apache runtime listener PASSED Automation Persistence crontab -u www-data -l CLI cron active on 1-minute schedule PASSED Firewall Enforcement sudo ufw status verbose Ingress ports restricted to SSH/Web PASSED Directory Isolation /var/moodledata www-data ownership with restricted root PASSED Database Integrity mariadb-check -u root -p --all-databases Zero orphaned schemas or table corruptions PASSED Log Rotation Cycle /etc/logrotate.d/apache2 Daily rotation enforced with 14-day TTL PASSED Production Deployment Success LMS dashboard rendering successfully after the bare-metal provisioning and network isolation phases.\n7. Experimental Integration \u0026amp; Rollback Decision: Local AI (Ollama) To introduce AI-assisted learning features to the LMS, I ran a Proof of Concept (PoC) integrating a local Large Language Model (LLM) through Ollama directly on the server.\nDuring testing, the Dell PowerEdge R420\u0026rsquo;s hardware constraints (CPU-only inference, 16GB ECC RAM, and no dedicated GPU) caused severe processing bottlenecks. AI response latency was unacceptably high, and inference drove CPU utilization high enough to threaten the responsiveness of the core Moodle web server.\nHardware Telemetry During AI Inference Resource monitoring over SSH showing the ollama daemon consuming 97.8% of CPU cycles and starving the Apache and MariaDB worker threads on the Xeon E5-2403 processor.\nEngineering Decision: I aborted the AI integration and rolled the server back to its baseline configuration. In production, core platform stability, reliable uptime, and a seamless user experience take priority over experimental features.\nKey Takeaways \u0026amp; Operational Impact Bare-Metal Performance Efficiency: Removing the hypervisor layer eliminated virtualization I/O overhead and gave the workload dedicated access to physical SAS spindles and raw CPU cycles during assessment submission spikes. Security by Default: Strict isolation between web assets and dynamic data stores removes the primary attack vector of unauthenticated arbitrary file uploads. Reproducibility Through CLI: Capturing the stack in shell scripts and CLI installation flags lets any future hardware refresh or cold-site recovery be orchestrated in minutes rather than hours. ","permalink":"https://thenickvendetta.pages.dev/writeups/moodle-baremetal-deployment/","summary":"End-to-end bare-metal provisioning, LAMP stack architecture, performance tuning, and automated disaster recovery workflows for an enterprise Moodle LMS deployment.","title":"Production Deployment: Moodle LMS on Bare-Metal Dell PowerEdge R420"},{"content":"Hi, I\u0026rsquo;m Nick.\nI am a Networking \u0026amp; Infrastructure Specialist with a core foundation in Computer Networking, actively developing expertise at the intersection of Cybersecurity, Artificial Intelligence (AI), and Electronics. My focus is on bridging physical hardware deployments, secure network architectures, and intelligent automation.\nI am currently completing my Diploma in Computer Networking at University College TATI (UC TATI), and I recently finished my industrial attachment at Jabatan Perkhidmatan Teknologi Maklumat (JPTM). There, I supported enterprise-grade network operations, from deploying production-ready LAMP stacks on bare-metal Dell PowerEdge servers to executing core switch migrations across campus facilities.\nMy approach to technology is multidisciplinary. I apply sound networking principles alongside proactive security verification methodologies to design, audit, and harden resilient systems. My passion for electronics drives me to analyze and engineer at the physical hardware layer, from configuring custom router firmware to examining modem chipset architectures. I also leverage AI tooling and locally hosted models to streamline infrastructure workflows and strengthen system analysis. Within my homelab, I rely on open-source solutions to replicate real-world enterprise scenarios in controlled, isolated environments.\nBeyond formal coursework, I regularly evaluate network policies, orchestrate virtualized environments, and assess emerging open-source tooling, continuously refining my homelab architecture to remain current with evolving security trends.\nTechnical Snapshot:\nNetworking \u0026amp; Systems: VLAN Segmentation, Subnetting, Core Switch Migration (Ruijie, H3C, Cisco), Ubuntu Server, LAMP Stack Cybersecurity (Purple Team Approach): Enterprise Firewalls \u0026amp; Hardening (Fortinet, UFW), Proactive Security Verification \u0026amp; Network Traffic Auditing (Responder, Bettercap, used in authorized lab environments to identify and remediate protocol-level weaknesses), Digital Forensics \u0026amp; Incident Analysis (Wireshark, REMnux, Flare VM) Hardware \u0026amp; Electronics: Bare-Metal Provisioning, Custom Router Firmware (OpenWrt), IoT \u0026amp; Network Hardware Virtualization, Containers \u0026amp; AI: Proxmox, VMware, Docker, Kubernetes (K8s), Local LLMs (Ollama) I am currently expanding my homelab environment and documenting my technical journey, continuously refining my infrastructure and security methodology in preparation for enterprise environments.\n","permalink":"https://thenickvendetta.pages.dev/about/","summary":"\u003cp\u003eHi, I\u0026rsquo;m Nick.\u003c/p\u003e\n\u003cp\u003eI am a Networking \u0026amp; Infrastructure Specialist with a core foundation in \u003cstrong\u003eComputer Networking\u003c/strong\u003e, actively developing expertise at the intersection of \u003cstrong\u003eCybersecurity\u003c/strong\u003e, \u003cstrong\u003eArtificial Intelligence (AI)\u003c/strong\u003e, and \u003cstrong\u003eElectronics\u003c/strong\u003e. My focus is on bridging physical hardware deployments, secure network architectures, and intelligent automation.\u003c/p\u003e\n\u003cp\u003eI am currently completing my Diploma in Computer Networking at University College TATI (UC TATI), and I recently finished my industrial attachment at Jabatan Perkhidmatan Teknologi Maklumat (JPTM). There, I supported enterprise-grade network operations, from deploying production-ready LAMP stacks on bare-metal Dell PowerEdge servers to executing core switch migrations across campus facilities.\u003c/p\u003e","title":"About Me"}]