Arham Sayyed, a Mumbai-based full-stack developer and security researcher, ran a three-part cybersecurity workshop on 7 September 2026 at ITM Skills University's School of Future Tech in Kharghar, in collaboration with Haxnation, for B.Tech students across three academic years. This post is a complete recap of what was actually taught, session by session: the tools used, the vulnerabilities demonstrated live, the exact mechanics behind each exploit, and the hands-on labs students worked through themselves.
Workshop information:
- Instructor: Arham Sayyed
- Organization: Haxnation
- Venue: ITM Skills University's School of Future Tech, Kharghar
- Date: 7 September 2026
- Topics: Web security, SQL injection, Wireshark, DevSecOps, CI/CD security, GitHub Actions, honeypots, intrusion detection, detection engineering
The workshop ran as three separate sessions back to back: one for Second Year B.Tech students, one for Third Year B.Tech students under the Cybersecurity Specialization track, and one for Final Year B.Tech students, also under the Cybersecurity Specialization track. Six hours, three batches, one continuous idea running through all of it: security is something you learn by breaking things yourself, not by watching a slide deck describe someone else breaking them.
Arham Sayyed's Cybersecurity Workshop at ITM Skills University
ITM Skills University's School of Future Tech invited Arham Sayyed to bring a full day of hands-on cybersecurity training to its Kharghar campus, part of a broader push to give engineering students practical exposure to security work well before they graduate into it. Cybersecurity roles increasingly expect candidates to have touched real tools before their first job, not just studied the theory behind them, and a single elective course rarely covers the gap between "understands the OWASP Top 10 as a concept" and "has actually run a SQL injection payload against a real database."
Rather than a single generic talk, the day was structured as three distinct, escalating sessions, each scoped to where a batch actually was in its coursework, and each built around real, working tools rather than slideware standing in for them. Every session followed the same underlying philosophy: show a real exploit live, before any theory, then hand students the exact same environment to attack themselves. No simulations standing in for real vulnerabilities, no toy examples that don't map to anything real. Burp Suite, Wireshark, GitHub Actions, and a hand-built honeypot and intrusion detection system, all running for real, in front of the room, all tested end to end the night before so nothing failed live.
What Is the Cybersecurity Specialization Track?
Third Year and Final Year batches at ITM Skills University's School of Future Tech follow a Cybersecurity Specialization track within their B.Tech program, a focused stream layered on top of the core computer engineering curriculum specifically covering security topics: network defense, application security, governance and compliance, and increasingly, the kind of DevSecOps and detection engineering skills covered in Sessions Two and Three of this workshop. Second Year students, not yet on the specialization track, received the foundational Session One instead, giving every batch content actually matched to their level rather than a single one-size-fits-all talk.
Session One: Web Security and Network Analysis (Second Year B.Tech)
The first session ran for the Second Year B.Tech batch and covered web application security and network traffic analysis from the ground up, assuming zero prior security background, since this batch had not yet started the specialization track.
Arham Sayyed opened the session the same way a professional penetration test actually starts: a live login bypass, demonstrated before a single slide of theory. From there, the session built out the full picture, starting with the fundamentals almost nobody's coursework actually covers directly: what HTTP is, what a request and response actually contain, and why the protocol has no built-in memory of who you are between one page load and the next.
What a Proxy Is, and What Burp Suite Actually Does
Before naming any specific tool, the session covered what a proxy is in general: software that sits between a browser and a server and passes traffic through itself instead of letting it travel directly. Whoever controls that proxy can read, and critically, edit, traffic before it ever reaches the server it was addressed to.
Burp Suite, made by the UK security company PortSwigger, is a proxy built specifically for that second part, editing traffic on purpose, so a tester can study exactly what happens when a request is tampered with. It has been the default tool of the web application penetration testing industry since roughly the mid-2000s, and Burp Suite Community, the free edition used throughout this session, ships with an embedded Chromium browser already configured to route through the proxy, removing the usual fifteen minutes of manual certificate and proxy configuration that stalls most introductory Burp tutorials.
SQL Injection, Demonstrated Live
Students then watched, and later reproduced themselves, a real SQL injection login bypass. The underlying mistake is almost always the same across real applications: a login check builds its database query by directly pasting submitted input into a string, rather than treating that input strictly as data. Typing ' OR '1'='1' -- into an email field, with any password at all, rewrites the query's logic entirely. The OR '1'='1' clause makes the WHERE condition true regardless of the actual credentials, and the trailing -- comments out the rest of the original query, including the password check itself, so it never runs. The result is a successful login as whichever user the database happens to return first, typically the administrator account.
Students then worked through a real SQL injection lab on PortSwigger's own Web Security Academy, the same free, industry-recognized platform used by professionals preparing for the Burp Suite Certified Practitioner exam. The specific lab, "SQL injection vulnerability allowing login bypass," uses the identical technique demonstrated live, in a fully isolated, disposable environment built for exactly this purpose.
Packet Analysis and the Real Difference Between HTTP and HTTPS
The second half of the session moved into network traffic analysis with Wireshark, free, open-source packet capture software that has been the default tool taught in networking courses worldwide since it was renamed from Ethereal in 2006. Students were walked through what a packet actually contains, a header describing where it came from and where it is going, and a payload carrying the actual content, before capturing a live login attempt themselves.
The centerpiece of this half was a live before-and-after demonstration: the exact same login form, submitted with the exact same credentials, once over plain HTTP and once over HTTPS. Over HTTP, filtering the capture and following the HTTP stream revealed the submitted username and password in fully readable plain text. Over HTTPS, the same filter on the same login showed nothing but ciphertext, because a TLS handshake had already encrypted the connection before a single byte of the actual form data left the browser. One honest caveat came with it: HTTPS defeats a packet sniffer sitting outside the machine, but does nothing about a proxy like Burp Suite, which the browser was explicitly configured to trust.
Students closed out Session One with hands-on networking challenges on a capture-the-flag platform, applying the same filter-and-follow-stream technique against real capture files to reinforce the skill in a graded, self-paced environment.
Topics covered in Session One:
- HTTP fundamentals: requests, responses, and statelessness
- What a proxy is, and why Burp Suite is built around that concept
- Burp Suite fundamentals and web exploitation
- Hands-on SQL injection, including a live login bypass and its exact mechanism
- PortSwigger Web Security Academy labs
- Packet analysis with Wireshark
- HTTP vs HTTPS, and what a TLS handshake actually changes
- Hands-on capture-the-flag networking challenges
Session Two: DevSecOps and CI/CD Pipeline Security (Third Year B.Tech, Cybersecurity Specialization)
The second session was delivered to the Third Year B.Tech batch under the Cybersecurity Specialization track, and shifted focus from web applications to CI/CD pipelines, treating the build pipeline itself as a genuine attack surface rather than deployment plumbing that happens to exist alongside the real application.
Two Buckets, Six Pillars
The session opened with a framing carried through the rest of the day: every pipeline compromise is either unauthorized tampering, someone changing what gets built or how, or unauthorized disclosure, something leaking that should not have. Six specific pillars of pipeline security were mapped across those two categories: build source, build process, build server, and build pipeline under tampering; build environment and build secrets under disclosure.
Two of those pillars were covered as concept-only stories, since neither is safe to demonstrate hands-on. Dependency confusion, the build process risk, was explained through Alex Birsan's well-documented 2021 research, in which publishing a public package under the same name as a company's internal package caused package managers to silently prefer the attacker's version over the real one, affecting real companies including Apple, Microsoft, and PayPal. The build server risk was explained through the well-known danger of an exposed, unauthenticated Jenkins script console, which hands an attacker direct code execution on infrastructure that usually holds real deployment credentials.
A Pipeline That Looks Completely Green
The live demonstration opened with a pipeline that looked entirely normal, every check passing, nothing flagged, and then walked through exactly why that signals less than it appears to. Students were shown a real, planted secret still recoverable from git history long after the file that originally introduced it had been deleted in a later commit, since deleting a line from the working tree never deletes the commit that added it. Anyone running git log -p against the full history, or using GitHub's own commit search, could recover it in seconds.
Two more disclosure mechanisms were demonstrated: a secret printed in full, plain text into a GitHub Actions log through a debug line, because GitHub only automatically masks values that have been explicitly registered as secrets, never plain environment variables, no matter how sensitive their name sounds. And a secret shipped unintentionally inside a downloadable build artifact, generated at build time and swept up by a packaging step that copied everything in an output folder without anyone deciding that on purpose.
Every vulnerability was paired immediately with its fix, not left as a talking point. Automated secret scanning with a tool like gitleaks, added as a single workflow step, catches both the git-history leak and the log leak at once, since it scans committed workflow content as well as commit history. Branch protection requiring a genuine second reviewer, with the author's own approval explicitly excluded from satisfying that requirement, closes the segregation-of-duties gap that exists by default on any fresh repository or personal fork.
A Real Repository, Forked and Fixed
Students then forked a real, purpose-built vulnerable pipeline repository, containing the exact issues demonstrated live, and worked through finding and fixing each one themselves. Submissions were validated live against a shared leaderboard built entirely on GitHub Issues and GitHub Actions: each issue template mapped to one vulnerability class, an automated workflow checked the submitted flag against a stored value, and a correct answer closed the issue automatically with a live-updating rank.
Topics covered in Session Two:
- The two-bucket framing: unauthorized tampering vs unauthorized disclosure
- Dependency confusion and real-world supply chain attacks
- Exposed Jenkins script consoles and build server risk
- Segregation of duties and branch protection
- Recovering secrets from git history after deletion
- GitHub Actions log masking, and exactly where it does not apply
- Secrets leaking through downloadable build artifacts
- Automated secret scanning with gitleaks
- Hands-on exploitation and remediation of a live, forkable vulnerable pipeline
Session Three: Honeypots and Intrusion Detection (Final Year B.Tech, Cybersecurity Specialization)
The final session, for Final Year B.Tech students under the Cybersecurity Specialization track, went furthest into building rather than using existing security tooling, and closed the day by tying every hour of it back to real industry practice.
What a Honeypot Actually Is
A honeypot is a target that exists purely to be attacked. It has no real users and no real data, so any traffic it receives is either a mistake or an attacker, with nothing in between, which makes everything a honeypot logs suspicious by definition. The session distinguished low-interaction honeypots, which fake just enough to be convincing, from high-interaction honeypots, which run genuine software and accept real risk to capture more detail, and explained why the low-interaction approach was the deliberate choice for this exercise.
Rather than installing an existing honeypot framework, students were given a small web application, built with Express and backed by a real embedded SQL engine rather than a simulation, containing three genuine, working vulnerabilities: SQL injection on the login form, weak, guessable admin credentials, and stored cross-site scripting through a guestbook feature that rendered submitted messages with zero output escaping. Alongside it sat a second, hardened server: the same login flow, but with a properly hashed password and a parameterized query, so the identical SQL injection payload that worked against the honeypot did nothing against it, a direct, visible contrast between vulnerable and secure code handling the exact same logic.
Students extended the honeypot with vulnerabilities of their own choosing before a few were called up to demonstrate what they had added, with the strongest additions merged into one shared honeypot that, by the end of the session, had genuinely been built collectively by the room rather than handed down.
From Signature Detection to a Real Threshold Rule
The second half of the session covered intrusion detection from first principles: signature-based detection, matching traffic against a library of known-bad patterns; anomaly-based detection, flagging deviation from a learned baseline of normal behavior; and threshold-based detection, simply counting events and firing once a number is crossed within a time window. Students were shown that a genuinely large share of real production alerting is built on the third, simplest category, not the more sophisticated-sounding first two.
Every request against the honeypot was tagged with an anonymous session identifier, assigned on first contact through a cookie rather than relying on IP address, since every attacker in the same room shares an IP on a shared network. Students then examined a hand-written, JavaScript-based intrusion detection script watching the honeypot's activity log in real time, implementing a single rule: five or more login attempts from the same session within ten seconds triggers an alert.
A live, fast attack against the honeypot triggered that alert within seconds of the fifth attempt. A second attack, run against the exact same target with the exact same wordlist, was then paced deliberately at three-second intervals instead, and slipped entirely underneath the same threshold, twelve attempts, zero alerts, an honest and real limitation of threshold-based detection rather than a flaw in the exercise, and exactly the gap that real attackers who understand detection systems deliberately exploit.
Mapping the Day Back to the Real Industry
The session closed by naming the real tools every piece of the day's exercise mirrors at production scale: Cowrie and T-Pot as real honeypot platforms used in SOC training and research, GreyNoise as a commercial company built entirely on turning honeypot telemetry into a threat intelligence product, Snort, Suricata, and Zeek as real network intrusion detection engines, and Wazuh and fail2ban as the closest real analogues to the hand-written detection script, both fundamentally watching a log and counting events past a threshold. Sigma, a platform-agnostic format for writing detection logic once and translating it into whatever query language a given SIEM platform speaks, was shown directly alongside the session's own JavaScript threshold rule to make the mapping concrete rather than asserted. The session's brute-force detection was tied to MITRE ATT&CK technique T1110, the shared, precise vocabulary security teams worldwide use to describe this exact behavior, and the day closed by naming the career paths this kind of work leads into: SOC Analyst, Detection Engineer, and Threat Hunter.
Topics covered in Session Three:
- What a honeypot is, and low interaction vs high interaction design
- Building a web honeypot with Express: SQL injection, weak credentials, stored XSS
- A hardened comparison server, and exactly what makes it hardened
- Anonymous session tracking and full activity logging
- Signature-based, anomaly-based, and threshold-based intrusion detection
- Writing a JavaScript-based threshold detection script from scratch
- Simulating live attacks and triggering real-time alerts
- Testing slow-rate attacks designed to evade threshold detection
- Real industry tools: Cowrie, T-Pot, GreyNoise, Snort, Suricata, Zeek, Wazuh, fail2ban
- Sigma detection rules and the MITRE ATT&CK framework
- Career paths: SOC Analyst, Detection Engineer, Threat Hunter
Frequently Asked Questions
What is a honeypot in cybersecurity?
A honeypot is a decoy system with no real users or data, deployed specifically to attract and record attacker behavior. Because it serves no legitimate purpose, any traffic it receives is inherently suspicious, making it a useful, low-noise source of real attack data.
What is DevSecOps?
DevSecOps is the practice of integrating security checks directly into the software development and deployment pipeline, rather than treating security as a separate, later stage. It covers securing the source code, the build process, the build server, the pipeline configuration itself, the deployment environment, and any secrets or credentials the pipeline handles.
What is SQL injection?
SQL injection is a vulnerability where user-supplied input is inserted directly into a database query without being properly separated from the query's actual logic, allowing an attacker to alter what the query does, commonly used to bypass login forms or extract data the application was never meant to expose.
What is an intrusion detection system (IDS)?
An intrusion detection system monitors activity, whether network traffic or system logs, for signs of malicious behavior, using signature matching, anomaly detection, or threshold-based rules, and raises an alert when it finds something worth a human's attention.
What is the difference between HTTP and HTTPS?
HTTPS is HTTP with an additional encryption layer, TLS, negotiated before any application data is sent. HTTP traffic travels in plain, readable text; HTTPS traffic is encrypted end to end between browser and server, though it does not protect against something running locally on the same machine, such as a trusted proxy.
Hands-On Cybersecurity Training, Start to Finish
Across all three sessions, the format stayed consistent: a real exploit demonstrated live first, the underlying concept explained second, and a genuine hands-on lab third, whether that meant a PortSwigger Web Security Academy lab, a forkable vulnerable GitHub repository, or a self-built honeypot and detection script. Nothing in any of the three sessions ran as a simulation standing in for the real thing, and every piece of infrastructure used across the day, from the Burp Suite setup to the vulnerable pipeline repository to the honeypot's embedded database, was tested end to end in advance rather than assumed to work.
Thank You
A huge thank you to Ayaan, who was there through all three sessions, helping keep everything running smoothly from setup to wrap. Thank you as well to ITM Skills University and the School of Future Tech for hosting the day, and to every student across all three batches, Second Year, Third Year, and Final Year B.Tech, who showed up, asked sharp questions, and actually broke things.
About Arham Sayyed
Arham Sayyed is a Mumbai-based full-stack developer, security researcher, and cybersecurity educator, working across MERN, TypeScript, and Next.js in both product development and freelance client work. He lectures on cybersecurity and related subjects for BSc CA/BCA students under the Mumbai University NEP syllabus, and builds practical cybersecurity training infrastructure, including the vulnerable pipeline repository and the honeypot and intrusion detection setup used in this workshop. He is a contributor to Haxnation, a cybersecurity community running a CTF platform, meetups, and workshops like this one.
Top comments (0)