![\"Example](\"https://raw.githubusercontent.com/haxnation/blog/main/blog/param-jasani/breachforce-meetup/imgs/deployment-manifest-nginx-k8s.PNG\")
\n This blog is a summary of what was taught at Haxnation Meetup Mumbai held on 27th June 2026.
\n\nBefore beginning the summary, I would like to tell you that if you are reading this and you did'nt show up, then you missed some serious fun and learning, come down to meetups whenever you are free, this session was packed with back to back questionaire and we had a wonderfull time learning and having fun together.
\nAlright alright, enough with promoting our community, so before you all cuss me virtually or cuss me in your heads, I will begin with my usual thing of summarizing the meetup down.
\nGRC stands for Governance, Risk, and Compliance - the three core components that keep an organization secure and legally sound.
\nTraditional GRC was designed for humans, operating at human speed with periodic audits and annual risk reviews. But what happens when AI runs the enterprise?
\nDr. Deepak highlighted six critical categories every GRC professional must own:
\n\n\nNote on BFSI Spotlight:\nIn the financial sector, these risks manifest as AI credit scoring biases (e.g., scoring applicants lower based on geography instead of credit history) or fraud detection models silently failing and being overridden by operators without an audit trail.
\n
We should extend, not replace, our existing frameworks (like ISO 27001, ISO 42001, NIST AI RMF, and RBI/SEBI guidelines). The 4-layer model includes:
\nThe DPDP (Digital Personal Data Protection) Act 2023 is live and AI is squarely in its scope:
\nTo summarize, here are the actionable steps for GRC professionals:
\n\n\n\"GRC professionals are the new AI guardians.\" - Dr. Deepak D. Kalambkar
\n
Alright, now this is where the fun begins. If Session 1 was about building the walls, Session 2 is about understanding the people who try to walk right through them - while looking like they belong there.
\n\n\nThink about it - when you receive an email from \"HR\" asking you to review a new policy document, your first instinct is to click the link, not to check the email headers. That's exactly what phishing exploits: the fact that we trust our daily workflows and the people we interact with.
\n
This part was really interesting. Mahadev made a point that really stuck:
\n\n\nThis is a crucial mindset shift. Anyone can clone a website and send a phishing email using a template. But if you don't know why your email got blocked or how the target's email gateway flagged it, you're not doing security - you're doing guesswork. Understanding the defensive side first is what makes you effective on the offensive side.
\n
Now this is where it gets really juicy. Mahadev covered the various detection methods that email security gateways, proxies, and security tools use to catch phishing - and by extension, what an attacker needs to understand if they want to operate professionally in red team engagements.
\n.com, .org, .in part. Security tools maintain lists of TLDs that are commonly abused for phishing, such as .xyz, .top, .click, .buzz, .rest, etc. These are cheap to register and frequently used by attackers, so email gateways flag or block emails coming from or linking to these TLDs..com, .org, .net, or country-code TLDs like .in to avoid suspicion. Using a legitimate-looking TLD is step one in making a phishing domain blend in.Now that we've covered how detection works and how people try to get around it, Mahadev broke down what a phishing operation actually requires from an infrastructure standpoint. This is important for red teamers and pentesters who need to set up professional, realistic engagements, and how to prevent the target org from reaching us.
\nmicosoft.com instead of microsoft.com, googel.com instead of google.com). Users often don't notice a single character difference.microsoft.org instead of microsoft.com).Mahadev then showed us two real phishing templates to demonstrate how legitimate these emails can look.
\nThe first template was an email that says something along the lines of \"Your Azure Cloud Storage is full, please login to review and manage your files.\" - a perfectly normal-looking notification that anyone using Azure would expect.
\nNow here's the interesting part - the phishing page uses URL rewriting (also called a transparent proxy or relay). When the victim enters their credentials on the fake login page, the attacker captures the credentials, and then the page actually logs the user into the real Microsoft portal using those same credentials. From the user's perspective, they typed their password, hit enter, and boom - they're on their actual Azure dashboard. Nothing suspicious happened, right? Wrong. The attacker already has the creds sitting in their logs.
\n\n\nThis is what makes modern phishing so dangerous - the victim never even realizes they were phished because they end up on the legitimate site. No error page, no weird redirect, no \"hmm that was strange\" moment. Just a smooth, clean login experience - except someone else now has your password.
\n
The second template was an Amazon voucher email. We've all seen these - sometimes we get mails about certification discounts, reimbursements, gift cards, or \"You've won a voucher!\" type deals. These are extremely effective in corporate environments because employees are used to receiving benefits, training reimbursements, and discount codes from HR or their organization's learning platforms. You see a ₹5000 Amazon Gift Card in your inbox, and your brain goes \"nice!\" before it goes \"wait, is this legit?\"
Before we get into the tooling and the war story, let's quickly cover the email authentication mechanisms that defenders rely on and attackers need to understand (or abuse).
\n~all) instead of a hard-fail (-all), the receiving server may still accept the email - just mark it as suspicious. Attackers also exploit SPF by sending emails from compromised servers that are in the SPF record, or by using domains that have overly permissive SPF records (e.g., include:_spf.google.com which covers all of Google's infrastructure).none (do nothing, just report), quarantine (send to spam), or reject (drop the email entirely). It also provides a reporting mechanism so domain owners can see who is sending emails on behalf of their domain.p=none (monitoring mode) and never move to quarantine or reject. This means even if SPF and DKIM fail, the email still gets delivered. Attackers love this.Now this was the absolute highlight of the session. Mahadev walked us through an actual red team phishing engagement he performed on an organization. This wasn't a hypothetical - this was a real operation, and the way it played out was wild.
\nThey did the usual - set up phishing infrastructure, sent convincing emails, and harvested user credentials. Standard stuff so far. Multiple employees fell for the phish and their credentials were captured.
\nNow here's where it gets interesting. The organization had an active SOC team, and the SOC detected that something was off. The SOC team sent out a legitimate email to the affected employees saying something like - \"You have clicked on a phishing link. Please click here to reset your password immediately.\"
\nNote - this was a real email from the actual SOC team, not an impersonation. The SOC was doing their job. But Mahadev and his team were watching everything unfold in real-time from the compromised accounts, and they had to act fast.
\nHere's the thing - Mahadev's team had already hijacked the user sessions by stealing cookies and tokens. So even if the user resets their password, the already-active session remains valid. Logging in and having an active session are two different things. A password reset changes the authentication credential, but it doesn't necessarily invalidate existing sessions that were already authenticated.
\nMaking it worse, this organization was using old Office 365 - and in older O365 implementations, resetting the password does not automatically log out already signed-in devices. So Mahadev's team was sitting pretty with full access even after password resets.
\nOn top of that, as soon as they saw the SOC email come in, they quickly added their device as a trusted device on the compromised accounts. This meant that even if the user went through a full password reset flow, the attacker's device would remain authorized because it's now \"trusted.\"
\n\n\nSomeone from the audience asked - \"If we are hijacking sessions, doesn't the session eventually expire?\"
\nGreat question. Mahadev explained the concept of refresh tokens. Most modern authentication systems use short-lived access tokens paired with longer-lived refresh tokens. When the access token expires, the refresh token is used to silently obtain a new one without re-authentication. If the attacker continuously uses the refresh token before it expires, they can maintain access indefinitely - the session essentially never dies.
\nHowever, there are limits. If the organization is using server-side session management (like PHP or other server-side scripts), the server can enforce absolute session timeouts - meaning the session will be terminated after a fixed duration regardless of activity. Some systems also terminate sessions based on inactivity or anomalous behavior patterns. But many cloud services like O365 rely heavily on the refresh token model, and if the organization hasn't configured strict token lifetime policies, the attacker stays in.
\n
Mahadev mentioned that they don't compromise just one user at a time - they typically target 15-20 users from the organization simultaneously. Why? Because it helps them:
\nThis multi-user approach gives the red team a much clearer picture of the organization's actual security posture.
\nNow this was the really sneaky part. To prevent users from seeing the SOC's password reset emails and actually resetting their passwords, Mahadev's team created an inbox rule in the compromised email accounts.
\nThe rule was simple - if the incoming message contains specific keywords like \"RE: Password Reset Request\" or \"Password Reset Request\", automatically delete the message. This way, the SOC keeps sending warnings, but the user never sees them in their inbox.
But wait - the deleted messages were going to the Trash folder. A curious user might open their trash and find them. So how did they handle that?
\nLuckily, the organization was using a third-party email provider that had an option to configure auto-deletion timers for trash items. Mahadev's team turned on developer mode in the email settings and reduced the trash auto-delete timer to 1 hour. So even if a deleted SOC email landed in trash, it would be permanently purged within an hour - long before most users would think to check.
\nFor delivering phishing URLs, they used PWA (Progressive Web App) / OVA file techniques.
\n\n\nWhat is this? A PWA (Progressive Web App) is essentially a web application that can be installed on a user's device and behaves like a native app. Attackers can abuse PWAs by creating a malicious PWA that, when installed, opens a phishing page in what looks like a standalone application window - no browser URL bar visible, no obvious signs that you're on a fake site. The
\n.ova(Open Virtual Appliance) format can be similarly abused to package malicious environments. In this case, Mahadev's team leveraged developer mode to push URLs through PWA functionality, making the phishing delivery mechanism harder to detect by traditional email-based controls since the URL isn't sitting directly in the email body in a conventional way.
Eventually, the SOC caught on and blocked the attacker's infrastructure at the Proxy AutoConfig (PAC) level.
\n\n\nWhat is Proxy AutoConfig (PAC)? A PAC file is a JavaScript file that tells a web browser which proxy server to use for a given URL. Organizations deploy PAC files to route employee web traffic through their security proxies, where traffic is inspected, filtered, and logged. By adding the attacker's domains/IPs to the PAC file's blocklist, the SOC effectively cut off access for any employee whose browser was configured to use the corporate proxy.
\n
But here's the catch - some employees were connected via VPN, and the VPN implementation was not properly configured. These VPN-connected users were either not routing all traffic through the corporate proxy, or their VPN split-tunneling configuration allowed direct internet access bypassing the proxy. So even though the PAC file was updated to block the phishing infrastructure, the VPN-connected employees were still reachable and exploitable.
\n\n\nThis is a classic example of why defense-in-depth matters. A single control (PAC/proxy blocking) failed because of a gap in another control (VPN configuration). Security is only as strong as its weakest link.
\n
Mahadev then gave an overview of GoPhish, one of the most widely used open-source phishing frameworks for security assessments.
\n{{.FirstName}}, {{.LastName}}, {{.Email}}, {{.Position}} to personalize each email..Tracker variable that embeds a unique tracking pixel in each email. Each recipient gets a unique rid (recipient ID) parameter appended to URLs and tracking pixels. This allows the framework to track who opened the email, who clicked the link, and who submitted credentials - all tied back to individual users.Mahadev also mentioned Evilginx, which takes phishing to a completely different level.
\n\n\nThis is exactly what Mahadev was doing in the real-world engagement story above - Evilginx-style session token capture is how they were able to maintain access even after password resets.
\n
The audience had some great questions, and a few stood out:
\nMahadev clarified - logging in and stealing a session are two different things. A new login from an unfamiliar device/location would trigger alerts in most SIEM/security tools. But importing a stolen session token doesn't generate a \"new login\" event - it looks like a continuation of the victim's existing session. To the SOC, it appears as if the legitimate user is still using their account normally.
\nMahadev's honest answer was - in theory, yes, next-gen firewalls and advanced security solutions can detect session anomalies. But in practice, it's extremely costly for businesses to maintain such granular session inspection at scale. The compute and storage overhead of tracking every session's behavioral fingerprint across thousands of users is significant. So while the technology exists, most organizations don't deploy it at the depth required to catch this kind of attack.
\nHe said yes, if properly configured, the proxy would detect and block it. But here's where it gets interesting - some proxies like Zscaler cannot block the QUIC protocol.
\n\n\nWhat is QUIC? QUIC (Quick UDP Internet Connections) is a modern transport layer protocol developed by Google. Unlike traditional HTTPS which runs over TCP, QUIC runs over UDP and uses its own encryption (built on TLS 1.3). Under the hood, it uses UDP and WebSockets, and the flow of QUIC traffic is fundamentally different from standard HTTPS traffic.
\nMahadev explained that they set up a QUIC server and rendered an iframe on their server to load the target website. Because Zscaler (and similarly Netskope) cannot natively inspect or block QUIC traffic the same way they handle HTTP/HTTPS, the phishing page loaded through QUIC effectively bypassed the proxy's URL filtering and inspection capabilities. This is a known gap in several popular CASB/SWG (Secure Web Gateway) solutions.
\n
The rest of the session was a live demo - Mahadev walked through setting up campaigns in GoPhish, attaching payloads, configuring email templates, and demonstrating the full attack flow end-to-end.
\n\n", "url": "https://haxnation.github.io/blog/haxnation-mumbai-meetup-june26-summary", "title": "Summary of Haxnation Mumbai Meetup held on 27th June 2026", "summary": "This blog is a summary of what was taught at Haxnation Meetup Mumbai held on 27th June 2026.\n", "date_modified": "2026-08-09T04:00:00.000Z", "author": { "name": "Param Jasani", "url": "https://github.com/param-jasani" }, "tags": [ "GRC", "AI", "Security", "Phishing", "Social-Engineering", "Email-Security", "Evilginx", "GoPhish", "Session-Hijacking", "DPDP-Act-2023", "ISO-42001", "QUIC-Bypass", "Haxnation-Meetup-Summary" ] }, { "id": "https://haxnation.github.io/blog/htb-mumbai-meetup-18-summary", "content_html": "Bottom Line: The key takeaway from Mahadev's session was this - phishing is not just about sending a dodgy email. It's an entire operation that requires careful planning of infrastructure, domains, and evasion techniques. And on the flip side, as defenders, understanding this entire chain is what helps us build better detection and response mechanisms. Every detection method has a bypass, every control has a gap - but layering them together and continuously improving is what makes the attacker's job harder.
\n
This blog is a summary of what was taught at HTB Meetup Mumbai #18 held on 01st August 2026.
\nIn my opinion, the sessions were really fun and bite-sized. Let's see what happened....
\nIn the earlier days of application hosting, running a service meant renting a physical server, configuring DNS, and making sure the application was reachable from the outside world. The biggest challenge was reproducibility. A web app that worked perfectly on a developer's laptop could still fail on the server due to differences in environment, dependencies, or runtime configuration. This was the classic \"works on my machine\" problem.
\nTo solve this, cloud providers introduced managed services that made deployment simpler, enabled autoscaling, and allowed traffic to be distributed through load balancers. But that also introduced a new set of concerns, especially around vendor lock-in and portability. Moving an application from one cloud provider to another often meant reworking parts of the infrastructure and configuration.
\nThis is where containerization changed the game. Containers made applications lightweight, portable, and easier to deploy. But as organizations started running many containers, managing them manually became difficult. That is where Kubernetes entered the picture.
\nKubernetes, often abbreviated as K8s, became popular because it solved a very practical problem: how do you manage a large number of containers at scale?
\nInstead of deploying services manually, Kubernetes lets you define the desired state of your application and then automatically ensures that state is maintained. If a container crashes, Kubernetes can recreate it. If traffic increases, it can scale the number of replicas. If a service becomes unhealthy, it can replace it. This makes applications more resilient and easier to manage.
\nThe talk also highlighted that Kubernetes is not only about scaling. It is also about portability and flexibility. Unlike some vendor-specific platforms, Kubernetes is cloud-agnostic and can be deployed on-premises, in private data centers, or on public clouds. That makes it a very attractive choice for organizations that do not want to depend too heavily on a single provider.
\nBefore containers, virtualization existed, but it was still heavy. Virtual machines had their own full operating systems and required more resources. Containers were more lightweight because they shared the host operating system kernel while still providing application-level isolation.
\nThis made containers much easier to package and ship. Images became smaller, deployments became faster, and scaling became more practical. But when dozens or hundreds of containers started running together, orchestration became a necessity. Kubernetes was designed to fill that role.
\nThe session emphasized that Kubernetes is essentially an orchestration engine for containerized applications. It handles scheduling, networking, storage, service discovery, and self-healing. In short, it helps teams run modern distributed systems in a more structured way.
\n\n\nTo know/learn more about the architecture or related stuff, you can check out the K8s Concepts that were covered in other meetup
\n
One of the most important security topics in the session was secret management. Secrets are sensitive values such as API keys, access tokens, database passwords, SSH keys, and TLS material. If these are mishandled, they can become the easiest path to compromise.
\nThe speaker pointed out that Kubernetes secrets are not magically secure just because they are called secrets. By default, Kubernetes stores them as base64-encoded values, which is not the same as encryption. That means a misconfigured cluster can still expose them if access controls are weak. This is why secret management is such a major topic in cloud-native security.
\nThe talk also connected this to OWASP K03: Secrets Management Failures, which highlights how often organizations fail to securely store, rotate, or restrict access to secrets. Some of the common problems include:
\nThe session also discussed better approaches to secret handling. These include using dedicated secret management systems such as HashiCorp Vault or cloud-native services like AWS Secrets Manager or Azure Key Vault. The speaker emphasized that organizations should not rely on Kubernetes alone for all secret protection. A stronger design usually includes:
\nIn other words, secrets should be treated as a first-class security concern rather than an afterthought.
\nThe second half of the session focused on container escape. Sorry for my cringy analogy out there, but that is the only thing that came to my mind while writing. The speaker looked like morepheus too, jk :)\nA container escape happens when an attacker moves from a compromised application container to the underlying host or node. Once that happens, the attacker may gain access to other containers, shared volumes, cluster metadata, or even the host operating system itself.
\nThe talk explained that container escape is a serious risk because it turns an application-level compromise into a platform-level compromise. In a Kubernetes environment, that can quickly lead to lateral movement and cluster takeover.
\nSome of the techniques discussed included:
\nOne of the most commonly cited examples is the misuse of the Docker socket. If a container has access to the host's Docker daemon socket, it may be able to start additional containers with host-level access. This is exactly the kind of vulnerability that can turn a small foothold into a major breach.
\nA simple demonstration discussed during the session involved mounting the host filesystem into a container and then accessing the host environment from within it. The example command that was shown was:
\ndocker run -v /:/host -i alpine chroot /host bash
This is a classic illustration of how dangerous it can be when a container is given access to the host root filesystem. Once the attacker escapes to the host, the situation changes dramatically because the host often has access to secrets, logs, node credentials, and the broader cluster environment.
\nThe speaker also walked through a small demo involving a vulnerable DNS application and some practical exploitation scenarios.
\nAlso he recommended checking out - manipulation of Git Hooks to achieve RCE.
\nAlso a small pun for our Indian readers, the best practice while creating any container is described in a song, which goes like -
Andar se koi bahar na jaa sake, Bahar se koi andar na aa sake, socho kabhi aisa ho toh kya ho, socho kabhi aisa ho toh kya ho
Nothing will happen its just a wet dream of SOC team :)
After a long long long time, I finally heard something related to physical pentesting, IDK in our country, its a very underrated art. Like, I still remember that last time when I heard about something related to physical pentesting it was either Darknet Diaries or it was Deviant Ollam.
\nAnyways....\nNow what was the second talk really about? It focused on compromising the people part of physical pentesting... Yeah what we call Social Engineering, you all already get that from the title of the session.
\nCompromising the human brain or pressing the specific pain points of people to reveal information, noticing patterns, reading the room, etc etc... that's what all social engineering is all about, one of the dark arts of our industry.
\nThe speaker highlighted that this was one of those talks that should not be limited to just security people. If you are in any kind of professional environment, whether you are working in cybersecurity, sales, operations, support, or even everyday life, this talk hits home. Because at the end of the day, a lot of breaches do not start with a technical failure. They start with someone clicking, trusting, panicking, or being pressured into doing something they should not have done.
\nSocial engineering is basically the art of making someone do what you want by playing with trust, emotions, urgency, or bias. It sounds scary because it is. But it is also extremely useful to understand if we want to defend against it.
\nThe speaker highlighted a few pressure points like fear, panic, greed, desire, curiosity, guilt, obligation, urgency, motivation, and needs.
\nOne of the biggest themes of the session was trust. People trust things that look familiar, things that look official, and things that seem to come from someone who has authority. This is known as authority bias.
\nThe speaker talked about authority bias in a very practical way. If someone appears to be in charge, or if they mention a manager, a team lead, a receptionist, or even a senior executive, the other person may stop questioning and start complying. The whole point is not that the target is stupid. The whole point is that humans are busy, distracted, and often making decisions under pressure.
\nThis is why the speaker emphasized the importance of not treating every situation as normal just because it looks routine. A lot of people follow the process without thinking too much. And that is exactly where manipulation becomes possible.
\nThe talk also spent a good amount of time on emotional triggers. Fear makes people react fast. Curiosity makes them click. Greed makes them ignore caution. Guilt makes them feel bad for saying no. Empathy makes them want to help. All of these emotions have been used over and over again in phishing, scams, impersonation, and social attacks.
\nThe speaker made a very good point here: the attacker often does not need to be brilliant. They only need to know which button to press. If they can trigger the right emotion at the right time, the target may take the action without even realizing what is happening.
\nThe speaker also shared some examples from real-world experiences, especially around reconnaissance and preparation. Even if the target is a company, an office, or a building, the first step is usually to understand the environment. Who are the people involved? What does the place look like? What is the normal flow of people? What are the visible and invisible barriers? This is where OSINT and recon come into play.
\nThe talk explained that even basic public information can be valuable. Blueprints, building layouts, lanyards, IDs, office routines, public social media posts, and even casual observations can all become clues.
\nAnother big topic in the session was the pretext. A pretext is basically a believable reason or story that makes someone accept your presence or your request. You should appear like you belong there, tone should be calm, body language should be confident, etc. People will ask less questions if you really look like its your daily routine.
\nThe speaker explained that rapport building is not just about being friendly, Its about making the other person feel comfortable enough to continue the conversation, if he/she agrees to do what you say, voilà you already gained their trust, now you can exploit the person to reveal more information.
\nOne of the most practical ideas in the session was situational awareness. In simple terms, it means paying attention to what is going on around you. Who is nervous? Who is talkative? Who looks confident? Who looks out of place? Who is in a hurry? What is the normal flow of the environment? The speaker said that once you understand what normal looks like, it becomes easier to spot the unusual.
\nThis is an important lesson not just for security professionals, but for everyone. We often walk into a room, a meeting, or a conversation without really observing what is happening. But the people who are good at reading situations are usually the ones who are more difficult to fool.
\nThe speaker also emphasized body language and behavior. A person’s face, posture, gestures, and tone can reveal a lot. You do not need to become a mind reader. You just need to pay attention.
\nThe talk also touched on a very interesting idea: the alter ego. The speaker did not mean becoming fake or toxic. He meant developing a version of yourself that can step in when needed. In other words, you can train yourself to be calm, confident, and observant when the situation demands it.
\nThe speaker even talked about creating mental anchors and switching into a more controlled mindset. He said to create boxes with scripts of personas that you want to mimic in your mental space and whenever you want to be that person just think of the script and start mimicking it.\nAlso emotional detachment from the character is also a key part of this practice as you don't want to land up in a gray area where you can't figure out the difference between the real you and your persona.
\nKubernetes & Container Security (Session 1)
\nPsychology, Social Engineering & Physical Pentesting (Session 2)
\nThis blog is a summary of talk held by Qualys titled Surviving CERT-In's 12-Hour SLA Without Mythos on 1st July 2026.
\nPicture this: your security team closes 40,000 more vulnerability tickets this year than last year. On paper, that's a win. The charts trend the right way, the quarterly review goes smoothly, everyone claps.
\nExcept attackers didn't get 40,000 fewer ways in. If anything, they got more.
\nThat's not a rhetorical setup. It's what the numbers actually show. Research analyzing over a billion resolved vulnerability records tracked against the US government's Known Exploited Vulnerabilities (KEV) catalog, spanning more than 10,000 organizations from 2022 to 2025, found that the sheer volume of vulnerabilities closed grew 6.5x, from 73 million in 2022 to 473 million in 2025. Risk didn't shrink to match it. The share of critical vulnerabilities still sitting open a week after discovery actually rose, from 56% to 63%.1
\nRead that twice. Teams are working harder than ever and losing ground.
\nHere's the quiet lie most vulnerability management programs run on: a closed ticket means the problem is gone. It usually doesn't. A patch can get deployed and still leave the underlying attack path wide open. A \"critical\" CVE score can flag a system nobody could actually exploit, while a \"medium\" sits ignored on the one server an attacker cares about most.
\nCVSS tells you how bad a flaw could theoretically be. It says nothing about whether anyone can actually reach it, whether it sits in front of your crown-jewel systems, or whether a threat actor is using it right now. Independent research on the CISA KEV catalog has found that around 12% of confirmed, actively exploited vulnerabilities carry a CVSS score below 7.0, the threshold many organizations use to decide what even gets triaged.2 Treat every finding the same way and you end up busy instead of safe, which is exactly what the 6.5x number above shows happening industry-wide.
\nThere's a second, quieter problem underneath this one: most teams don't actually know what they're protecting in the first place. You can't triage what you can't see. Before prioritization, before remediation, before any of the rest of this, there's a visibility problem that has to get solved first.
\nMost enterprises don't have a clean asset list. Not really. There's a cloud instance a product team spun up without a ticket. An old on-prem box nobody remembers provisioning. A contractor's laptop still sitting on the VPN six months after the contract ended. A shadow AI tool someone installed to \"just try it out\" that's now quietly connected to internal data.
\nReal visibility means pulling from everywhere at once, not from a single scanner running a monthly sweep. A serious inventory has to account for:
\nGetting the full picture usually means combining several detection methods too: native agents and scanners, integration with whatever configuration management database the business already runs on, external attack surface scanning to see what the outside world can see, passive sensors to catch unmanaged devices that active scanning misses, and signal pulled from whatever other security tools are already watching pieces of the estate.
\nNone of this matters without business context, though. A raw asset list just tells you what exists. What actually drives prioritization is layering in:
\nHere's what that looks like in practice. Take a single cloud instance running a payment gateway application. As a bare vulnerability finding, it's one line in a spreadsheet, forgettable. Add context and it stops being forgettable fast: this is a Tier 1 critical system tied directly to revenue, it's running an unsupported, end-of-life web server, it has unauthorized remote-access software installed, it has no endpoint detection deployed, and its remote desktop port is exposed to the open internet. That's not a ticket anymore. That's the thing that should be keeping your CISO up at night, and now you actually know it exists.
\nA mature program also needs to extend that same visibility beyond traditional IT, into a few areas that get overlooked constantly:
\nThat's the actual job of prioritization: not ranking CVEs by severity, but ranking exposures, real ones, on real systems, tied to real business consequences.
\nSecurity teams love talking about severity. Boards don't care about severity. They care about money, and honestly, they're right to.
\nThere's a simple way to think about this:
\nRisk = Time exposed × Severity × What's actually at stake
\nThe variable almost nobody tracks is time, specifically, how long a known, exploitable flaw sits open before someone actually closes it. Call it your window of exposure. It's one of the better predictors of whether your program is working, and most companies have no real idea what theirs is.
\nWhere it lands makes a real difference. Programs built around verified, closed-loop remediation, where a fix isn't considered done until it's re-tested and confirmed, report average exposure windows around 18 days. The typical enterprise, running a standard ticket-and-hope process, sits closer to 67 days.1
\nEvery extra day in that gap isn't just a metric problem. It's a bill waiting to arrive. India recorded the highest average cost of a data breach anywhere in the world in 2025, at ₹22 crore (INR 220 million), a 13% jump from the year before.3 Incidents where shadow AI played a role cost an additional ₹1.79 crore on average, and it was among the top three cost drivers identified in the same research.3 Every day you shave off that exposure window is, quite literally, rupees taken off the table.
\nIf you want your CFO to actually listen in the next budget meeting, stop leading with vulnerability counts. Lead with what an open exposure is costing the business, per day, in currency they recognize. This is the shift a lot of security leaders still haven't made: moving from talking about attack surface to talking about risk surface, measuring cyber risk the same way the rest of the business measures everything else, in terms of probable loss, and reporting it in language a board can act on without a translator.
\nGood programs don't stop at \"we patched it.\" They run something closer to a four-step loop:
\nThat last step is the one almost everyone skips. A closed ticket says a task got done. A verified fix says the risk is gone. Those aren't the same claim, and only one of them should let you sleep at night. The service-level agreement that actually matters isn't \"ticket closed.\" It's \"exploit path confirmed closed,\" and very few programs measure against that bar today.
\nOnce you know what to fix, \"how\" becomes the bottleneck. Most organizations still route every fix through a human decision, and there simply aren't enough hours in the week for that anymore at the volume modern estates generate. A smarter approach maps each exposure to whichever action actually fits, automatically:
\nNone of this replaces judgment. It replaces the assumption that every single fix needs a person to manually decide, ticket, assign, chase, and confirm by hand, an assumption that simply doesn't hold up against a 6.5x increase in remediation volume.
\nIt's worth being honest about where AI actually fits into all this, because it cuts both ways.
\nOn the defensive side, mature platforms are increasingly running a mix of AI models rather than betting on one: lightweight, efficient models handling high-volume routine automation, and larger reasoning-focused models brought in for genuinely complex analysis, where cost matters less than getting the right answer. There's also a growing pattern of security vendors partnering directly with AI research labs on distinctly offensive-adjacent use cases, applied defensively: vulnerability research, zero-day discovery, exploit development, malware reverse engineering, and red teaming. Essentially, the same capabilities attackers are developing get pointed inward first, before someone else points them at you.
\nThat same shift is reaching further left into the development pipeline too. AI-assisted static code analysis is increasingly feeding straight into vulnerability management: findings from source code get imported automatically, runtime context gets applied to prioritize what actually matters, and the resulting list gets patched in order of real risk rather than however the code scanner happened to sort it.
\nThe uncomfortable flip side is that attackers are using the same category of tools to move faster too: faster reconnaissance, faster exploit development, more convincing social engineering. This isn't a distant concern either. In May 2026, India's insurance regulator directed every insurer in the country to submit a formal action-taken report on their AI cyber readiness, specifically citing the risk of frontier AI systems being used to accelerate attacks.4 AI hasn't changed what good security fundamentals look like. It's just made the cost of skipping them higher, and the timeline for getting caught shorter.
\nThis is where it stops being optional.
\nOn July 25, 2025, India's national cybersecurity agency, CERT-In, released a sweeping new set of Comprehensive Cyber Security Audit Policy Guidelines, and they read like someone took everything above and wrote it into law.5 Every organization, public or private, that owns or runs digital systems now has to undergo a full cybersecurity audit of its ICT systems at least once a year. Not a checkbox review. A real one.
\nA few details matter more than the rest:
\nRead between the lines and the message is blunt: if you don't already know your assets, understand your real exposure, and can translate it into terms a non-technical executive would sign their name to, you are not audit-ready. You're improvising under a legal deadline, with a compliance officer explaining to the board why they're about to personally attest to risk nobody actually measured.
\nOrganizations that already run mature vulnerability management, with full asset visibility, validated exposure data, and business-risk framing baked into every report, walk into this kind of audit with most of the hard work already done. Everyone else is building the plane while it's already being inspected mid-flight.
\nAnd CERT-In isn't the only regulator with a clock running. Indian security leaders answer to a stack, not a single body:
\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n| Regulator | What it actually requires |
|---|---|
| CERT-In | 6-hour incident reporting and 180-day log retention under the 2022 Directions, plus the 2025 audit guidelines above8 |
| DPDP Act | Rules notified in November 2025, with core obligations phasing in through May 2027, carrying its own breach-notification duties9 |
| RBI | IT governance directions for banks and NBFCs requiring a 6-hour initial report plus a 21-day root cause analysis, filed through its Centralised Information Management System10 |
| SEBI | A cyber resilience framework built around anticipate, withstand, contain, recover, and evolve, with mandatory vulnerability assessment and penetration testing11 |
| IRDAI | An AI cyber-readiness action-taken report required from every insurer, due May 20264 |
| NCIIPC | Incident reporting duties for operators of designated critical information infrastructure, layered on top of CERT-In's national reporting clock12 |
The good news, if there is one: every requirement in that stack, asset visibility, exploitability context, business-risk framing, proof of remediation, is exactly what a well-run vulnerability management program produces anyway. Build it for the business case, and you've basically built it for the regulators too. Treat compliance and good security as two separate projects, and you'll end up doing the work twice.
\nAs attackers lean harder on AI to speed things up, the fundamentals don't change. They just get less optional.
\nStop measuring your security program by how many tickets it closes. Start measuring it by how few days a real, exploitable risk sits open, what that number is costing you in rupees rather than reputation, and whether you could hand a regulator your asset list tomorrow without flinching.
\nThe regulators just made all three of those mandatory. You might as well get ahead of it.
\nThis blog is a summary of talks held at Antisyphon Training - Threat Hunting Summit 2026 on 17th June 2026.
\nThis keynote session posed more brainstorming questions that would drive the community to think and tinker around and identify effective approaches to AI enabled threat hunting.
\nAs we already know that AI attacks are on the rise, so what would happen if we as defenders use AI to our advantage?
\nFrom a threat actor's perspective, adopting AI is relatively straightforward and they use AI more aggressively as they are not concerned about collateral damage or unintended consequences, on the other hand defenders must take a far more measured and responsible approach while using AI for defense as it can inadvertently weaken an organization's security posture if not implemented properly.
\nHow the attackers/threat actors can cheat us -
\nModern security environments generate terabytes of telemetry everyday.\nThe sheer volume and velocity at which these telemetry gets ingested makes it difficult for humans to read and analyse it all, even large teams can't keep up with this scale.\nModern day threat actors with the help of AI operate at machine speed, so we have to act quickly as well which can only done with the help of AI, but we can't trust it as well.
\n\n\nThis is Hunter's Paradox — We can't hunt at scale without AI, but we can't fully trust the AI we need.
\n
In 2015, organizations increasingly recognized the need for threat hunting, driven by the fear that attackers could already be present in their environments and that traditional detection systems were insufficient, but people were not sure on what it was or how to perform it, there was no single framework to define that. So to teach people threat hunting and sell their product, Sqrrl Threat Hunting Loop was created. Sqrrl's framework was the first published \"how to\" for threat hunting.\nIt Focused on hypothesis-driven hunting and detection improvement.\nLater: PEAK Threat Hunting Framework (Splunk, 2023) was built on similar ideas.
\nBoth frameworks defined threat hunting as:
\n\n\n\"Any manual or machine-assisted process for identifying security incidents your automated detection systems missed.\"
\n
For many years this definition was valid as machine assited humans by accelerating investigations but at the end we needed a human to drive the hunt, but he thinks that this is coming to an end.
\nSo if it can't be manual or machine assisted then what it should be?\nNow David proposes a new definition as Threat hunting might be…
\n\n\n\"Any reasoning-driven process for identifying security incidents your automated detection systems missed.\"
\n
As today, humans are not only the ones who can reason, AI can also reason, these models are not perfect but it can do the work.\nSo if hunting is reason driven, then we should allow AI to drive the hunts.
\nNow we have to allow AI to drive the process, where should we start?\nWe can't just give AI so much data and tell it to hunt, we need some structure and guardrails to be really effective.
\nFaan picks up exactly where David's keynote left off.\nHe walks on the same line of questions that David presented us in the keynote and suggests what would happen if we replace human judgement with a pattern matching agent.\nTo present the problem to us, he takes help of an analogy.
\nNow how to solve this problem? One way would be to just relax the detection criteria so that the agent spots the variation as well. But it introduces another problem, i.e. False Positive Deluge.
\nSo if detection criteria is -
\n\n\nAlert based security is low resolution.
\n
So in a typical SOC environment, if we focus only on the alert part, from a machine's perspective it will be just a boolean value, i.e., it will be an alert or not one, but for us as humans there is more to it, we use initial breadcrumbs to derive a conclusion or there is some kind of chain of thoughts associated to it which drives our process to evaluate, we like to connect the dots to arrive at a conclusion, or for that matter make intuitive calls during the process, that is what human judgement is all about in threat hunting, we drive the process, we are involved in the detection itself and not just in reviewing the output.
\n\n\nThe main goal of threat hunting is not just to find threats, it's main goal is to drive overall improvement in security posture, as David reframed it in the PEAK framework.
\n
As David also highlighted in his keynote, the detection demand is increasing but human judgement can't dramatically scale with it and match the requirements.
\n\n\n\"We can dramatically scale human judgement through the intentional integration of an agentic layer in a threat hunting system.\"
\n
Identify where you can utilize transformer based intelligence to maximize strengths of your organisations while also retaining deterministic code and human intelligence, if there is a chance of AI hallucination then stick to the basics of using the good old fashion deterministic code. So it all boils down in identifying key areas where you can boost your overall security posture and use the strengths of all three.
\nKeypoints -
\nSo to cover all these keypoints he proposes 9 fundamental methods to integrate Agentic AI into existing systems.
\nYou cannot simply dump millions of logs into an LLM and tell it to \"find evil.\" Agents are designed for reasoning, not raw calculation. Doing so leads to context overflow, the \"lost in the middle\" fallacy, high latency, and spurious correlations. To bridge this gap efficiently, defenders must use:
\nPre-Emptive Data Analysis (Distillation): Using traditional compute to run statistical analysis on all the telemetry and then using that probability in your hypothesis generation.
\nOn-Demand Analysis & Retrieval: Leveraging frameworks like CodeAct or Roberto Rodriguez's concepts which helps in standardizing the tooling that the AI can use, then the AI can query and analyze data dynamically, after the generation of initial hypothesis.
\nRelational Structuring (Knowledge Graphs): KGs are a very efficient way to elucidate the relationships between different data entities, so first process your telemetry into KGs before agents deal with it.
\nAgentic Detection Engineering: After parsing IOCs from your intel feeds, use agents to run sigma detections on your telemetry.
\nGUI / Vision Mediation (Legion)
\nWe do standard LLM interactions by sending streaming tokens via an API call to the LLM and receive streaming tokens back as an answer, even when LLM runs a tool, its a json request to run the tool, the model can't really run the tool.\nSo the question arises that how do we preserve those values returned by different API calls that are running in parallel during hunts so that these values are accessible to future agents?\nThe answer to it is Knowledge Graphs.\nFaan highlights KGs as a highly effective way to map out this shared state, especially when tracking the complex connections between different entities during a hunt.
\nHunters love their tools, and agents can be given the ability to use them either by asking the harness to perform the action or through automated workflows. Models do not execute the tools directly; the harness makes the API call on their behalf.
\nDefault agent interactions often occur in a sequential manner, where a user asks a question and the model replies.
\nWhen scalling we want to move away from this sequential pattern, how to do that?
Skills are the evolutionary progression from simple \"prompts.\" It's where we concretize the fuzzy knowledge of organization (what lives in a hunter's head) into Standard Operating Procedures (SOPs).
\nCharacteristics: They must be executable, automatable, and atomic (targeting a very specific method or objective).
\nLifecycle: Skills should be composable (combinable), version-controlled, A/B tested, and shareable with the community.
\nDirection: You cannot just tell an agent to \"go find stuff.\" Skills provide the strict boundaries: \"Here is the telemetry, here is the specific thing you are looking for, and here are the conditional workflows and reference scripts to use.\"
\nEverything a base model knows lives in its pre-trained weights.\nThere are two flaws associated with it first is that the knowledge base lags behind by few months and another is that they are inherently flawed for enterprise defense because they know absolutely nothing about your specific organization, network architecture, or crown jewels.\nSo to give them the context, we can use mechanisms like RAG (Retrieval-Augmented Generation) or DuckDB to inject specific organizational context right when the agent needs it.
\nIntroducing a skills based node that allows for intentional reflection following a hunt to give suggestions of how it can improve itself. To simplify, After a hunt another agent will look into the hunt and ask questions that what was missed during the hunt while also coming up with suggestions to improve itself.
\nWhen you alter the system's architecture, prompts, or skills, you need a way to measure the impact of those changes.\nEval ensures that system improvements are driven by hard metrics and verifiable performance data, rather than just relying on \"vibes\" or gut feelings about the AI's output.
\nAs David mentioned in the keynote, introducing an AI agent layer inherently increases your attack surface.\nTherefore the threat actors can exploit the AI via prompt injection hidden within telemetry logs, manipulated MCP servers, or poisoned RAG databases.\nSo we should actively guard and remediate every vector where an attacker could theoretically influence or hijack the agent's reasoning.
\nSydney starts by presenting us the problem of Hunt Amnesia, what she simply means by that is our teams conduct a successful threat hunt and forget their own work; like 6 months or 1 year down the line, our teams are unable to remember that what queries were executed, the hypothesis or even what was the result of the hunt.\nShe highlights that in 2026, it's still one of the biggest things that lies between our threat hunting teams and AI augmented threat hunting.
\n\n\nThe Knowledge part in PEAK framework is the most important that most people skip. Knowledge is connected to all parts of the hunt, so it has to be compounded at each and every step of a threat hunt.
\n
ATHF is a framework in which AI agents join us in threat hunting cycle as collaborators, they do not replace us, they enable us.\nNow ATHF needs structured hunt notes, ATHF only works if our past hunts are readable to a human or even a model, so we need structuring, this is where LOCK comes in.
\nThe LOCK has four moves:
\nThese all four moves go in a single hunt file which is in markdown (.md) format.
The front matter is in YAML format, it contains facts like -
\nBelow front matter we have our body, this is where our LOCK format actually comes into play, we have our LOCK headings and their subsequent information as stated above.
\nThe above format makes it easier for AI to query it, the sections are predictable which helps our teams to stick with the structure and makes our job easier to maintain memory.
\nJust simply provide your AI agent the above created markdown files and ask questions related to your past hunts.\nMake a markdown hunt repo where you store all your previous hunts.
\nDuring the lunch break, Joe provided an introductory session on network threat hunting. The goal of this session was to help beginners collect, explore, and analyze network traffic in their home labs.
\nWhen analyzing network traffic, packets are built in layers to encapsulate specific tasks. A simple curl request requires around 11 packets just to fetch an HTML page. These are the layers that matter most during threat hunting:
Looking at raw packets (PCAPs) in Wireshark can be overwhelming due to the sheer volume of data.
\n\n\nThreat hunters live in the abstraction layer. We don't want to stare at individual packets; we want connection summaries to build a behavioral story.
\n
Joe showcased a simple, affordable pipeline for analyzing network traffic at home:
\ntcpdump (Linux/Mac) or tshark (Windows).tcpdump, and connect all your devices. Let it run for 24 hours to capture your entire local network's traffic..pcap file directly into the Zui UI, and it automatically converts it into Zeek logs.Hermon starts the talk by referring to the Pyramid of Pain.\nAs we all know, the top layer of the Pyramid of Pain is TTPs, as it is the most difficult IOC to change for an attacker.\nTTPs = Behaviors of a threat actor.\nSo tracking down these behaviors makes our threat intelligence a lot better, and this is exactly where RITA comes in.
\nWhen analyzing Zeek logs, there are a few command-line tools that come in handy:
\nzeek-cut, grep, awkBeacons are persistent, regular callbacks from a compromised machine (victim) to the attacker's Command and Control (C2) server.
\nwhoami).Hermon demonstrated the practical steps for analyzing this traffic using RITA's CLI interface. If you're ever unsure of what to do, running rita by itself provides a helpful list of available commands.
rita import --database=<database_name> --logs=<path_to_logs> to ingest the Zeek logs.rita listrita view <database_name> to explore the analyzed data.When viewing the data, RITA provides a table sorted by severity, containing several insightful columns:
\n*.malicious.com) is a strong indicator of DNS tunneling.Threat hunting doesn't always yield a malicious C2 server; in fact, most connections are benign. However, network hunting is incredibly valuable for identifying security gaps, maintaining inventory, and baselining.
\nFinding Poor Security Configs:
\nInventory & Shadow IT:
\nMany organizations start their threat hunting programs with the vague objective of \"finding bad,\" as the managers are not technical and don't know how to put this up, so the threat hunters have questions in mind like -
\nIt also lacks focus, leaving teams unsure if they should concentrate their attention on infrastructure, the perimeter, services, or the cloud.
\nHartman points out that building a program solely to look for \"bad\" creates a literal \"no-win situation\" for the security team:
\nThreat hunting is primarily a proactive activity used to identify threats that may have evaded detection. However, hunts can take several different forms:
\n\n\nThe ultimate goal of threat hunting is to improve the overall security posture of the organization.
\n
Before diving into specific telemetry or posture hunts, it helps to understand your current operational level. Referencing a framework created by David Bianco, Hartman outlines five tiers of threat hunting maturity:
\nHartman noted that most organizations are currently sitting in tiers 0, 1, or 2, or a hybrid of those levels. In these early stages, teams might merely use EDR to pick up IOCs or centralize logs without actively reviewing them unless an alert triggers. They lack a formalized structure.
\nThe goal is to transition out of the initial procedural stages and into the \"Innovative\" and \"Leading\" tiers. Reaching this maturity allows threat hunting to become automated and highly useful to other departments, such as the SOC, Red Team, Detection Engineering, and Cyber Threat Intelligence (CTI). For example, if CTI reports a new vulnerability, a leading program can simply qualify that they have already searched for and mitigated the issue, rather than having to spin up a reactionary, ad-hoc threat hunt.
\nThese hunts start out with a foundational question: \"How do we know what we know?\". IT might assure us that EDR is fully deployed, all assets are known, and subnets are documented. We might believe we know what our cloud environments look like and that our logs are perfectly centralized. However, asking the question might reveal that Linux or Mac logs are missing entirely. If you don't ask the question, you will never realize there is a gap you cannot see into.
\nYou must also ensure coverage across perimeters, firewalls, and third-party VPNs, as you never know where a threat group might pivot. You need to have the telemetry data first before you can actually hunt for threats.
\nThe most practical approach is to assume there are gaps and actively hunt for them to validate these claims. A critical outcome of finding a gap is feeding that information back into the threat hunt process to answer what might not have been seen while the gap was in place.
\nA practical example of \"watching the watchers\" is verifying your EDR deployment. Hartman provided a mathematical breakdown for this simple telemetry hunt:
\nX .Y1.Y2.Y3.(X - Y1) – Diff in Inventory system.(X - Y2) – Diff in AD.(X - Y3) – Diff in IP Space.Any discrepancies reveal clear gaps in telemetry. When you work to close these gaps and bring the numbers closer to zero, this gap closure can be reported to leadership as a reduction in exposure.
\nThere are numerous other simple questions you can ask to confirm the correct data is collected:
\nA significant portion of your hunting emphasis should lie with the organization's \"Crown Jewels\". Identifying these assets relies on asset management, Business Impact Analysis, Business Continuity Plans, and Disaster Recovery procedures. These critical assets could include employee and client information, HR data, proprietary information, and core web applications. Hunters need to define the specific threats targeting these assets, understand what would happen if they were compromised, and develop hunts to address these specific hypotheses.
\nWhen shifting into proactive hunting, there are four primary methodologies you can leverage:
\nA crucial realization for the longevity of any hunting program is that executives do not fund \"cool technical queries\".
\nTo secure buy-in, you must speak their language and translate technical findings into tangible business value:
\nThe talk focuses on the challenge of converting Threat Intelligence (TI) reports into actionable hypotheses. The core problem is that many TI reports just sit in email inboxes or Slack channels due to sheer volume and lack of prioritization. Lauren emphasizes \"intel-driven hunting,\" comparing it to a bank in Chicago that shouldn't hunt for malware targeting North Korean grocery stores. Threat hunters need to extract behaviors and connect the dots to create testable hypotheses, which is the first step toward using AI effectively.
\nLauren created a contract to ensure that an intelligence report becomes a structured and testable hypothesis, not just a summary or a list of IOCs. If the model can't fill all details, the hunt doesn't exist and needs more work. The process includes four non-negotiable steps for every report:
\nThe first step focuses on pulling out behaviors and sequences while dropping volatile indicators.
\n\n\nThe Prompt That Does It:\n\"From the report below, extract EVERY distinct behavior across the whole intrusion: process lineage, LOLBins, persistence, C2 technique, lateral movement, cred access, discovery, defense evasion, impact. List each variant — don't collapse them. IGNORE hashes, IPs, and single-use domains. Tag each with its kill-chain phase and the actual command / path. End with a count so nothing drops downstream.\"
\n
AI models often hallucinate or use stale training data, so mapping behaviors correctly is critical.
\n[VERIFY] for human review.You must define the exact data sources and event IDs required for the hunt. If the telemetry doesn't exist, that itself is a finding (a coverage gap).
\n\n\nHearth automatically filters hypotheses based on your available data sources so coverage gaps are obvious before starting.
\n
The final output is a repeatable shape for every hypothesis that scales from a solo hunter's notebook to a program's backlog. It includes six components:
\nWhat turns a basic summary into a runnable hypothesis? Lauren shared these prompt engineering pointers:
\n\n\nThe System Prompt:\n\"You are a senior threat hunter, not a chatbot. You turn threat reports into hunts a hunter can run today — rigorous and skeptical of your own output.\nRules you never break:\n- Hunt BEHAVIOR, not indicators.\n- Map to ATT&CK by behavior; use the most specific sub-technique. Unsure an ID exists? Say so — never invent one.\n- Ground every query ONLY in that hunt's named data source.\n- Every hypothesis ships with validation: expected hits AND the false positives to baseline.\n- Firm, narrow, specific. One behavior per hypothesis.\"
\n
Lauren showcased how she applied this structure to a real-world example: The DFIR Report, May 2026 — EtherRAT -> TukTuk -> The Gentleman. By pasting the full report link along with the one-shot prompt, the AI processed the entire intrusion chain.
\nThe single run successfully:
\nHere are three of the sharpest hunt cards generated from that single prompt (more examples are available on her GitHub repository):
\nLauren and the team have already built a system that automates this entire loop for the community, called HEARTH. Instead of threat intel dying in a Slack channel, it becomes a forkable community asset. You can try it yourself:
\nhearth.thorcollective.com/submit.html. It opens a pre-filled GitHub issue.Jason, an offensive security expert with 22 years of experience at Arcanum, presented a beta version of their upcoming content on defending AI. The talk was built entirely from an attacker's perspective — covering the 11 things he hates dealing with the most when red-teaming AI applications. These 11 layers form a \"Defense-in-Depth Stack\" and fall into two categories:
\n\n\nNone of these are foolproof on their own, but layered together, they create a defensible AI system.
\n
Jason demonstrated how attackers exploit AI systems using Prompt Injection. Attackers use tools like Parseltongue (built by jailbreak group BT6, led by Pliny the Prompter) to encode malicious prompts in hundreds of different encodings (e.g., Unicode circle letters) to bypass classifiers, guardrails, and built-in model safety tuning. He also highlighted a recent Meta chatbot bug where an over-scoped customer support agent allowed attackers to request a password reset code for the White House Instagram account and have it sent to an attacker-controlled email — all without ever logging in.
\n\n\nIf Meta can make mistakes like these, we can all make mistakes like these when implementing agentic systems.
\n
AI systems are still web applications at the end of the day, and foundational web hygiene stops many AI-specific attacks.
\n).\n\nGuardrails are essentially firewalls for LLMs.
\n
They inspect incoming messages for two things:
\nFeatures to look for in a guardrail:
\nUsing a frontier model from a major lab (OpenAI, Anthropic, Google) provides another layer because they come pre-tuned with built-in safety training to resist simple prompt injection and harmful content generation.
\nBefore passing a request to the main model, use a small, fast, cheap LLM as a gatekeeper to classify whether the user's input belongs in your system at all.
\nRAG is just hooking up a document data store to your AI app, but it introduces major risks if done carelessly.
\nBackend agents are what make AI apps powerful, but they need to be treated like employees with least-privilege access.
\nreadDoc and search permissions. Destructive actions like deleteUser or executeCode should be separated into a different, sandboxed agent or handled through a deterministic non-AI workflow entirely (like calling customer service or a web app flow).When agents interact with third-party APIs or internal data stores, enforce read-only access by default and lock down where data can go.
\nattacker.com, egress controls stop the request.While input guardrails filter what goes in, an output classifier filters what comes out of the model.
\nRestricting the number of tokens (input and output) that a model can process in a single interaction is a simple but effective control.
\nThis is a deterministic control that limits how many requests a user or session can make over a given time period.
\nThe final layer is about visibility. If all other layers fail, you need to be able to detect and investigate what happened.
\n\n\nThis layer ensures that even if an attacker breaches every other control, their activity is recorded and can be investigated forensically.
\n
Here is a compiled list of all the frameworks, tools, projects, and resources mentioned throughout the summit:
\nThis blog is a summary of talk held at Breachforce Meetup, Mumbai held on 21st June 2026.
\nContainerization relies heavily on two native Linux kernel features:
\nTo deploy resources in Kubernetes, we use YAML manifests. Here is a breakdown of the key elements in a standard Deployment manifest:
\napiVersion: Specifies the Kubernetes API version being used (e.g., apps/v1).kind: Indicates the type of Kubernetes object being created (e.g., Deployment).metadata.name: Specifies the name of the deployment resource.spec.replicas: Defines the number of Pods to run at any time.spec.strategy.rollingUpdate.maxSurge: The maximum number of Pods to be created on top of the desired count during deployment.spec.strategy.rollingUpdate.maxUnavailable: The maximum number of Pods that can be unavailable during deployment.spec.selector.matchLabels and spec.template.metadata.labels: Both labels should match to create a Pod.spec.template.metadata: Defines the Pod manifest.spec.template.spec.containers.name: The name of the container within the pod.spec.template.spec.containers.image: The name of the container image to pull and run.spec.template.spec.containers.ports.containerPort: The application listening/running port.\n A Kubernetes cluster consists of a set of worker machines, called nodes, that run containerized applications. Every cluster has at least one worker node.
\n![\"Kubernetes](\"https://raw.githubusercontent.com/haxnation/blog/main/blog/param-jasani/breachforce-meetup/imgs/Kubernetes-Architecture-Diagram.jpg\")
\n The Control Plane manages the worker nodes and the Pods in the cluster.
\n\n\nIntegration Example: Security tools like Qualys VMDR can coordinate with the Controller Manager. When a vulnerability is found and patched, Qualys can trigger an update to the desired state, prompting the Controller Manager to gracefully roll out the patched containers while terminating the vulnerable ones, ensuring zero downtime patching.
\n
The Data Plane contains the components that run on every node, maintaining running pods and providing the Kubernetes runtime environment.
\nDuring the session, an audience member asked which area generally presents the largest attack surface: the Infrastructure, the Application, or Kubernetes itself. The speaker responded that the Kubernetes side often presents a much larger and complex attack surface due to its numerous components, configurations, and internal networking.
\nThe assessment of a Kubernetes environment mainly follows two approaches:
\nkubeconfig file. The goal is to determine how much damage an attacker can do purely from the outside (e.g., exploiting a vulnerable public-facing application to gain initial access to a pod, and then attempting to break out of the container or move laterally).kubeconfig): The tester is provided with a kubeconfig file (often simulating a compromised developer's machine or insider threat). The goal here is to assess the impact and see how far privileges can be escalated within the cluster due to misconfigurations in RBAC (Role-Based Access Control) or weak policies.When modeling threats for Kubernetes, consider the following:
\netcd), Secrets, Volumes (Data Breach), Container Images (Private Repository), or Compute Resources (e.g., for Crypto Mining).\n\nMost Dangerous Finding in a K8s Pentest\nWhen someone from the audience asked the speaker what was his most dangerous finding during a K8s pentest, Abhishek shared that it was Hardcoded Credentials.
\nBy discovering hardcoded credentials, he was able to access the complete Kubernetes dashboard. Because there was absolutely no security hardening in place, he gained Admin access. From there, he changed the authorization configurations, changed user passwords to achieve complete cluster takeover, and effectively locked the client out of their own environment to demonstrate the severity of the misconfiguration.
\n
The Kinsing hacker group has been actively exploiting various flaws to expand their botnet primarily for Cryptojacking (unauthorized use of compute resources to mine cryptocurrency).
\nA highly sophisticated attack campaign targeting AWS EC2 and other Kubernetes infrastructure. It perfectly demonstrates the critical risks of lateral movement.
\npacu, and peirates. They attempt to exploit IMDSv2 to retrieve tokens and subsequently AWS credentials.peirates to further exploit Kubernetes and frequently change C2 domains (utilizing public services) for defense evasion.\n\nContainer-to-Kubernetes Lateral Movement
\nSCARLETEEL 2.0 highlights the severe danger of Container-to-Kubernetes Lateral Movement, where a single container compromise can lead to a full Kubernetes account breach.
\nWhen questioned about this lateral movement, the speaker clarified:
\n\n
\n- By default, Kubernetes is relatively secure due to modern RBAC (Role-Based Access Control) mechanisms.
\n- However, if an attacker successfully escapes a container, they might gain access to the underlying platform (like minikube) and use command-line tools like
\nkubectlto interact with the cluster.- The \"Complete Mess\" of Caveats: In reality, lateral movement can take many convoluted paths:\n
\n\n
\n- Container to Container: Jumping to a container that has higher privileges or sensitive credentials mounted.
\n- Container to Cluster: Gaining direct API access to the Kubernetes cluster from within the compromised pod.
\n- Container to Runtime: Accessing the container runtime itself (e.g., containerd, docker, cri-o).
\n- Container to Node (Host): In cases of misconfigured shared mounts, an attacker might achieve arbitrary file writes on the host file system. This allows them to break out to the underlying node and potentially steal highly privileged credentials.
\n
According to the presentation, attackers typically gain their initial foothold through the following vectors:
\ncluster-admin bound to default service accounts), storing secrets in plaintext or environment variables, and running containers with privileged: true or as root.kube-apiserver, kubelet), container runtimes (like runc vulnerabilities e.g., CVE-2024-21626), or workloads.A growing trend in the threat landscape is the weaponization of legitimate security tools:
\nAbhishek ensured the session was highly interactive by providing attendees with a pre-configured Ubuntu Virtual Machine (OVA file). This lab environment had everything completely set up for us—a huge shoutout and credit to the speaker for removing the friction of setting up a local cluster!
\nThe lab heavily featured Kubernetes Goat, an intentionally vulnerable cluster environment created by Madhu Akula, designed to help security professionals learn and practice Kubernetes security practically.
\nGetting the lab running inside the VM was straightforward:
\nminikube start to spin up our local Kubernetes control plane and worker nodes.\n![\"Starting](\"https://raw.githubusercontent.com/haxnation/blog/main/blog/param-jasani/breachforce-meetup/imgs/minikube-start.png\")
\n kubernetes-goat directory and ran the provided script: bash access-kubernetes-goat.sh. This automatically created the necessary port forwards (e.g., ports 1230 to 1236) and hosted the vulnerable application guide locally on http://127.0.0.1:1234.\n![\"Setting](\"https://raw.githubusercontent.com/haxnation/blog/main/blog/param-jasani/breachforce-meetup/imgs/kubegoat-deply.png\")
\n Abhishek kicked off the walkthrough with the first scenario: Sensitive keys in codebases.
\n.git directory publicly. An attacker can navigate to url.com/.git/config to verify the exposure..git directory locally using git-dumper. From there, they can view the commit history, find previous commit hashes, and change the HEAD to an older commit. In the walkthrough demonstration, reverting to an older commit revealed a .env file that had been accidentally committed, ultimately exposing highly sensitive application credentials.The second example demonstrated a critical vulnerability: breaking out of a container to gain access to the underlying host node.
\ncapsh --print inside the compromised pod. This command prints the current capabilities of the container, including the Bounding set and Ambient set, which helps attackers understand what privileged actions they are allowed to perform.\n![\"Demonstration](\"https://raw.githubusercontent.com/haxnation/blog/main/blog/param-jasani/breachforce-meetup/imgs/capsh-demo.png\")
\n ls /host-system/.chroot /host-system bash, the attacker effectively breaks out of the container's isolated filesystem and drops into a root shell on the underlying host node.crictl pods, successfully listing all pods running on that specific node, demonstrating a complete node compromise.The final scenario highlighted the dangers of overly permissive Role-Based Access Control (RBAC), a common issue addressed in Madhu Akula's blogs.
\nwebhookapikey, but due to a misconfiguration, the attached service account has broader permissions./var/run/secrets/kubernetes.io/serviceaccount/ to find the mounted service account credentials (ca.crt, namespace, and token).TOKEN, CACERT, APISERVER), the attacker uses curl to authenticate directly with the Kubernetes API Server.curl --cacert ${CACERT} --header \"Authorization: Bearer ${TOKEN}\" -X GET ${APISERVER}/api/v1/secrets successfully dumps all secrets in the namespace (including a highly sensitive vaultapikey). This perfectly illustrates how failing to implement the principle of least privilege can turn a minor pod compromise into a massive data breach.The latter half of the presentation shifted focus towards defense, monitoring, and automated auditing.
\nAbhishek emphasized the importance of runtime security monitoring. He showcased Falco as a vital tool for SOC teams.
\nAfter a short break, the session resumed with Abhishek deploying the official Kubernetes Dashboard using the minikube dashboard command.
![\"Unsecured](\"https://raw.githubusercontent.com/haxnation/blog/main/blog/param-jasani/breachforce-meetup/imgs/minikube-dashboard.png\")
\n To wrap up the technical demonstrations, Abhishek ran through a battery of popular open-source auditing and scanning tools to show how defenders can proactively identify the vulnerabilities discussed throughout the meetup:
\nkubectl and passing them to KICS. The resulting scan report clearly highlighted exposed secrets (e.g., k8svaultapikey and k8swebhookapikey), proving its utility in finding hardcoded credentials in configurations.\n![\"KICS](\"https://raw.githubusercontent.com/haxnation/blog/main/blog/param-jasani/breachforce-meetup/imgs/kicksscan-output.png\")
\n kube-bench to evaluate the cluster against CIS Kubernetes Benchmarks. The tool highlighted specific security postures (PASS, FAIL, WARN) for various components, such as whether API server token expiration was properly configured or if profiling was disabled on the controller manager.\n![\"kube-bench](\"https://raw.githubusercontent.com/haxnation/blog/main/blog/param-jasani/breachforce-meetup/imgs/kubebench-output.png\")
\n kubescape scan, summarizing the overall security posture of the cluster and identifying misconfigurations against established security frameworks. He showed various results returned from Kubescape, highlighting what was not enabled on the control plane and detailing compliance scores. He then specifically ran kubescape scan framework mitre to evaluate the cluster against the MITRE ATT&CK framework, highlighting high-severity findings such as \"Applications credentials in configuration files\" (with compliance score details), \"List Kubernetes secrets\", and \"Writable hostPath mount\".\n![\"Kubescape](\"https://raw.githubusercontent.com/haxnation/blog/main/blog/param-jasani/breachforce-meetup/imgs/kubescape-scan-output.png\")
\n grype (e.g., grype alpine:latest), which is a vulnerability scanner for container images and filesystems. This tool is essential for identifying CVEs (Common Vulnerabilities and Exposures) within the base images and packages running in your cluster before they can be exploited.\n![\"Grype](\"https://raw.githubusercontent.com/haxnation/blog/main/blog/param-jasani/breachforce-meetup/imgs/grype-output.png\")
\n To conclude the session, Abhishek moved back to the slideshow to discuss fundamental Kubernetes hardening and security concepts.
\nThe golden rule underlying all these concepts is simple: Follow the \"Principle of least privilege.\"
\nHe outlined several key areas for securing a cluster, including Open Policy Agent (OPA), Network Policies, Secrets management, and most notably, Pod Security Policies.
\nA Pod Security Policy (PSP) is a cluster-level resource that controls the security-related attributes of pods, specifically managing container privilege levels. Key guidelines when defining a PSP include:
\n/proc filesystem mount: Protect sensitive kernel parameters.NET_RAW if ping isn't required).\n\nCrucial Note on Pod Security Policies
\nWhen a PSP resource is created, it does nothing on its own. You must explicitly authorize it using RBAC (Role-Based Access Control) for it to take effect!
\n
While PSPs are great for Pod-level security, what if you need to control fields in other resources or enforce complex, custom logic? This is where Open Policy Agent (Gatekeeper) comes in.
\nGatekeeper acts as a customizable admission controller. It gives you the ability to:
\nExample: Restricting Image Registries\nAbhishek showed an example of a Gatekeeper constraint (K8sAllowedRepos) designed to enforce the use of only allowed container registries (e.g., openpolicyagent/ and myregistry.com/). When a user attempts to run a pod with an unapproved image (kubectl run my-pod --image=nginx), the admission webhook intercepts the request and strictly denies it, returning a \"Forbidden\" error.
If OPA is your configuration enforcer, a Network Policy is your internal cluster firewall.
\nBy default in Kubernetes, pods can communicate freely with each other. Network Policies allow you to lock this down by explicitly defining Ingress (incoming) and Egress (outgoing) traffic rules at the Namespace or Pod level.
\nwebapp pod only on ports 80 and 443 from specific internal IP subnets.kube-dns) and cannot arbitrarily reach out to the internet or other namespaces.Abhishek posed an important question: \"Where do I version control my secrets?\"
\netcd, you configure the Kubernetes API server to encrypt secrets at rest using a transit encryption key managed by Vault (via a vault-kubernetes-kms provider).Finally, he ran through rapid-fire configurations for hardening the critical components of the Kubernetes cluster itself:
\n--insecure-port flag to 0, and ensure --insecure-bind-address is not set.--anonymous-auth=false). Ensure requests are authorized by setting --authorization-mode=Webhook (avoiding AlwaysAllow) and strictly defining the CA certificate (--client-ca-file=/etc/kubernetes/pki/ca.crt).Control Plane Ports to Monitor:\nHe also shared a quick reference table of control plane ports. A good quick-check is to try curling these ports to ensure they are properly secured:
As a final takeaway, Abhishek provided a rapid-fire list of essential tools that can help audit, secure, and monitor Kubernetes environments:
\nCAP_SYS_ADMIN or forcing runAsNonRoot).One morning, our domain appeared on VirusTotal with detections from nine security vendors. This is the story of how we investigated the issue, reached out to the vendors, and ultimately got the false positives cleared.
\n\nA story of the day our domain was flagged by over 9 security vendors on VirusTotal and how we contacted the vendors to get the false positives removed.
\nOn 31st May 2026, we shared one of our blog posts in our community group. Shortly after, one of our community members reached out and mentioned that they were unable to open our website because Bitdefender was flagging the domain as malicious.
\nOur founder immediately looked into the issue and scanned the domain on VirusTotal. To our surprise, the domain had been flagged by more than 9 security vendors.
\n![\"VirusTotal](\"https://raw.githubusercontent.com/haxnation/blog/main/blog/param-jasani/misc/imgs/vt-fp-flag.png\")
\n And that's when his hunt began.
\nAfter some digging, Our founder discovered that there isn't a central \"remove false positive\" button on VirusTotal.
\nInstead, you need to contact each security vendor individually and submit a false positive report for review.
\nHe then pinged me and asked me to continue from there and resolve the issue.
\nSo I started searching for every vendor's submission portal, support page, email address, and any available process for reporting false positives.
\nTo save others from going through the same research, I've listed all the resources we used below.
\n| Vendor | False Positive Submission Method |
|---|---|
| Kaspersky | https://opentip.kaspersky.com/ |
| Fortinet | https://www.fortiguard.com/webfilter |
| Bitdefender | https://www.bitdefender.com/consumer/support/answer/29358/ |
| CRDF Labs | https://threatcenter.crdf.fr/false_positive.html#false-positive-form |
| G DATA | https://www.gdata.de/help-en/general/GeneralInformation/submitFileAppURL/ |
| Lionic | https://www.lionic.com/supports/report-false-positive/ |
| Sophos | https://support.sophos.com/support/s/filesubmission?language=en_US |
| Adminus | Email: samples@adminus.net |
| CyRadar | https://cyradar.com/reportfp/ |
For Kaspersky, we used their Threat Intelligence portal:
\nhttps://opentip.kaspersky.com/
\nYou need to enter your domain, fetch the results, and then submit a request for reanalysis. The process is explained in detail here:
\nhttps://support.kaspersky.com/kaspersky-for-windows/21.25/troubleshooting/other/1870
\nFor Adminus, there isn't a dedicated false positive submission portal.
\nInstead, send an email to:
\n\nUse the subject line:
\nFalse Positive Request for [domain-name]
\nand include details about the detection along with the domain you want reviewed.
\nNote: The vendors and links below were aggregated from community resources (such as the False-Positive-Center GitHub repo, OneHourSiteFix guides, and other public references). These are not part of our personal experience and have not been tested by us. Links and processes can change over time, so always verify on the vendor's site and use a professional email. Include your VirusTotal link, exact detection name, and a clear explanation that it's a legitimate site.
\nOfficial contact list from VT if you can't find anything on vendors - https://docs.virustotal.com/docs/false-positive-contacts
\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\nNote that these lists from GitHub, VT and OneHourSiteFix are not updated, they can be used as a fallback if you can't find anything on the vendor.
\n
Additional Tips (from aggregated sources):
\nAfter submitting false positive reports to all the vendors that had flagged our domain, we waited for their review.\nWithin few hours, the detections started disappearing one by one.
\nAnd within 48 hours, all our queries were solved.
\nBy the end of the process, our domain had been cleaned and was no longer being flagged by the vendors that had initially marked it as malicious.
\n![\"VirusTotal](\"https://raw.githubusercontent.com/haxnation/blog/main/blog/param-jasani/misc/imgs/vt-domain-clean.png\")
\n If your domain is being flagged on VirusTotal, don't panic.
\nIn many cases, the detections may simply be false positives. The key is to identify which vendors are flagging your domain and then submit review requests directly to those vendors.
\nHopefully, this expanded list of resources saves you even more time. And also thank you to all the teams on vendor's side who resolved our queries so fast!!
", "url": "https://haxnation.github.io/blog/vt-fp", "title": "How We Cleared VirusTotal False Positives for Our Domain", "summary": "One morning, our domain appeared on VirusTotal with detections from more than nine security vendors. This is the story of how we investigated the issue, reached out to the vendors, and ultimately got the false positives cleared.\n", "date_modified": "2026-06-06T08:00:00.000Z", "author": { "name": "Param Jasani", "url": "https://github.com/param-jasani" }, "tags": [ "misc", "VirusTotal", "False-Positives", "Antivirus", "Domain-Reputation" ] }, { "id": "https://haxnation.github.io/blog/the-purdue-model", "content_html": "In this blog, we'll explore the Purdue Model, its different levels, and its role in modern industrial cybersecurity.
\n\n\n\n\n
\n- Purdue Model is named so because it originated at Purdue University.
\n- Theodore J. Williams, a professor at Purdue University and Director of the Purdue Laboratory for Applied Industrial Control, led the effort.
\n
Ok, enough of beating around the bush, let's get straight into learning the layers of the model.
\nThe Purdue Model divides an industrial environment into multiple hierarchical levels. Each level has its own purpose, systems, and responsibilities.
\n![\"ICS](\"https://raw.githubusercontent.com/haxnation/blog/main/blog/param-jasani/ics-ot-sec-blogs/imgs/purdue-model.jpg\")
\n \n\nPoints to remember -
\n\n
\n- Lower Levels = Physical Industrial Processes = Critical/Higher Potential Impact = Tough to Reach
\n- Higher Levels = Business Operations = Larger Attack Surface = Easier to reach
\n
| Level | Name | Primary Systems & Devices | Security Focus & Controls | Likelihood of Compromise | Potential Impact |
|---|---|---|---|---|---|
| 5 | Enterprise Network | Corporate IT, ERP, email, internet | Standard IT security, largest attack surface | Higher | Moderate to high business impact |
| 4 | Business Logistics | Plant-level IT, scheduling, maintenance systems | IT/OT boundary security | Higher | Moderate to high business impact |
| 3.5 | Industrial DMZ | Firewalls, proxies, jump servers, data diodes | Critical buffer zone, controlled data exchange | Medium | Critical buffer breach (pivoting risk) |
| 3 | Operations Management | MES, historians, engineering workstations | Highest risk in OT; strict access controls | Medium | High operational impact |
| 2 | Supervisory Control | SCADA servers, HMIs | Strong access control, continuous monitoring | Lower (if properly segmented) | Very high physical/process impact |
| 1 | Basic Control | PLCs, RTUs, DCS controllers, IEDs | Protocol security, strictly limited access | Lower (if properly segmented) | Very high physical/process impact |
| 0 | Physical Process | Sensors, actuators, motors, valves, instruments | Physical security, device hardening | Lower (if properly segmented) | Highest physical safety/process impact |
The Purdue Model’s real power in cybersecurity comes from the concepts of Zones and Conduits, which were formalized in IEC 62443.
\nEasiest Scenario as we have an empty ground to play with.
\nLegacy environments are difficult to deal with, so let's segregate it into phases -
\n\n\nCompensating Controls for Legacy Systems
\n
\nIn many brownfield environments, some Level 0–2 devices are too old to support modern segmentation or cannot be taken offline. In these cases, compensating controls are used to reduce risk:\n
\n- Protocol Gateways: Act as secure intermediaries that translate protocols while enforcing strict allow/deny rules on commands and data.
\n- Network Access Control (NAC): Restricts which devices can join the network and what they can access.
\n- Unidirectional Gateways (Data Diodes): Allow data to flow in only one direction.
\n
This blog is a summary of what was taught at HTB Meetup Mumbai #16 held on 30th May 2026.
\n\nSo let's dive into it (hey, wait a minute, why do I feel like I am starting to sound like chat gipidy day by day, anyways, let's start)
\n\n\nCTSS was one of the first time-sharing operating systems, allowing multiple users to share a single mainframe (IBM 7090/7094) with private files.
\n
![\"Single](\"https://raw.githubusercontent.com/haxnation/blog/main/blog/param-jasani/htb-meetup/imgs/single_comp_auth.png\")
\n\n\nWhat is configuration management?\nIn context of authentication and user provisioning, configuration management means managing the settings and rules that control how users are created, updated, assigned permissions, and removed across systems.
\n
![\"Configuration](\"https://raw.githubusercontent.com/haxnation/blog/main/blog/param-jasani/htb-meetup/imgs/config_manager_multi_comp_auth.png\")
\nYears later, technological advancements led to introduction of more devices into the network.\nLets take and example, we introduce a managed router into the network.
\n\n\nManaged switches/routers: Configurable via CLI, SNMP, web interfaces, or central tools. Unlike \"dumb\" unmanaged devices (plug-and-play), managed ones allow VLANs, QoS, monitoring, port security, and firmware updates.\nWe can provision these like nodes using config manager
\n
![\"Router](\"https://raw.githubusercontent.com/haxnation/blog/main/blog/param-jasani/htb-meetup/imgs/routerauth.png\")
\nYears later, ISP entered the scene. What does it offer to the organisation?
\nSo how do we solve this problem? Let's see...
\n![\"ISP,](\"https://raw.githubusercontent.com/haxnation/blog/main/blog/param-jasani/htb-meetup/imgs/isp_ras_pubnw.png\")
\nAdd a Remote Access Service (RAS) at the edge as the single point of connection between the public network and the ISP's internal network. The RAS (also called a Network Access Server (NAS)) accepts connection attempts from the untrusted public side and forwards authentication/authorization requests to an Authentication Service (AS) that lives on the ISP/internal side.
\nWhy this separation? The RAS is on the untrusted edge; the AS is inside the trusted ISP/domain. Clients reachable from the public internet can talk to RAS, but they should never be trusted to store long-term secrets (no credential caching on the edge when the path may be compromised).
\nSo what is the catch here? any consequence? Yes, every login may require the RAS to query the AS, increasing traffic between RAS and AS. To limit bandwidth/complexity, protocols were designed to be simple and lightweight.
\nThat's where our hero comes in!!
\nRADIUS (Remote Authentication Dial-In User Service) was created for that model: a lightweight, client/server AAA protocol where the NAS (RAS) forwards credentials to a RADIUS server (the AS) and receives simple codes back:
\nRADIUS uses a shared symmetric secret between NAS and server (no expensive public-key handshake at every transaction), and simple packet types to keep bandwidth and processing small. That design trades end-to-end cryptographic guarantees for simplicity and lower per-request cost.
\n\n\nNote: RADIUS and credential handling\nSome authentication methods require the server to know the user's actual password (or something equivalent to it) in order to verify the login.
\n\n
\n- Why this happens: some NAS-side auth methods (PAP, certain CHAP deployments) require the verifier to compute or compare values derived from a user's secret. That often forces a RADIUS server to hold plaintext or password-equivalent material so it can validate requests.
\n- Risk: storing password-equivalent data on RADIUS (or on any front-line AAA box) increases blast radius — a compromised RADIUS/proxy exposes many user secrets and enables lateral abuse.
\n- Practical limitation: hashed+salted passwords (one-way hashes) are safest for storage, but they make some challenge/response schemes (that need the raw secret) impossible without an intermediary that can perform verification.
\n
RADIUS Accounting (RFC 2866) supports session records:
\nWhat happens? an example flow -
\nIf you cannot or do not want to trust the internal network or want to avoid hammering the AS with repeated full authentications, introduce a ticketing model (PS: Our soft inro to the three headed god: The Kerberos):
\nThis offloads repeated authentication from the AS/KDC and enables single sign-on (SSO). Kerberos is primarily symmetric-key based (with public-key extensions) and relies on a KDC (AS + TGS) and synchronized time for replay protection.
\nMany deployments pair Kerberos with a directory (LDAP / Active Directory). LDAP stores user principals, service principals, and attributes (groups, policies). In Windows ecosystems the Domain Controller (DC) bundles KDC functionality, LDAP directory, DNS, and other services required for centralized identity and service discovery.
\n\n\nMetadata Services (169.254.169.254): Cloud providers use a local, non-routable IP address to allow VMs to query information about themselves (metadata). This address is only accessible from inside the VM or the internal network.
\n
\n\nServer-Side Request Forgery (SSRF): an attacker forces a server to make network requests on their behalf. In cloud environments, SSRF is often used to trick the web server into querying the provider's metadata service.
\n
\n\nCommand Injection & RCE: command injection occurs when unsafe, user-supplied data is passed to a system shell. Remote Code Execution (RCE) is the ultimate goal: arbitrary commands running on the target machine remotely.
\n
The researcher found a 5-step exploit chain that leads to complete system compromise:
\nHasPrefix(artifact, \"command:\") instead of enforcing an exact match.command:bash -c 'rm -rf /', which are passed directly to cmd.Run() and exec.CommandContext() without sanitization.![\"Agent](\"https://raw.githubusercontent.com/haxnation/blog/main/blog/param-jasani/htb-meetup/imgs/full-exploit-chain.png\")
\n/etc/shadow dumps, application secrets), establish persistence (SSH backdoors, rootkits, cron jobs), or deploy wide-scale ransomware or supply chain attacks.\n\nLessons Learned for Hunters:
\n\n
\n- Read public source code to find open attack surfaces.
\n- Combine minor issues into critical vulnerabilities through chaining.
\n- Never assume link-local addresses are safe.
\n- If you believe in your finding after a rejection, escalate with solid evidence.
\n
This blog introduces the fundamentals of ICS/OT security, including key industrial cybersecurity terminology, the differences between IT and OT environments. We’ll also explore core concepts and common components used in industrial systems.
\n$ ./greet.sh
Hey folks!! Param this side, your technical blog partner.
I will be starting a blog series on ICS/OT security.
If you are reading this then most probably you and I are on the same path and believe me I am too new to this domain and will be navigating my and your path through this.
So my blog series will be covering notes, difficulties I faced, labs that I will do and much much more, I will keep this blog series raw as much as possible.
Besides this blog series I will posting some blogs here and there, so do check them out.
$ whoami
I am Param, named after a supercomputer but not one!!, trying to learn and get better in this field everyday.
I always say that if Morpheus appeared in my life and gave me an option to choose between blue pill and red pill, I would always choose blue pill, as I like to dwell into my illusion of protecting people in a SOC environment, ~ you saw what I did there ;) .
\n\nSummary,
\n
\nEverything that deals with the physical/operational world is OT and\nthe control brains inside the OT world that actually make decisions to open/close valves, stop motors, adjust temperature comes under ICS.
\n\nNote -
\n
\nAll ICS is OT, but not All OT is ICS.
![\"ICS](\"https://cdn.prod.website-files.com/645a45d56fc4750d4edd96fe/672500beb02d8cd3ba644608_652db196f291207aec0433eb_ICS-Cybersecurity-03.webp\")
\nWe have looked into how ICS and OT are different from each other, now let's cover how IT and OT are different from each other.
\n| Feature | Information Technology (IT) | Operational Technology (OT) |
|---|---|---|
| Primary Focus | Data management and processing. | Physical process control and safety. |
| Core Priority (Triad) | Confidentiality, Integrity, Availability. | Availability, Integrity, Confidentiality. |
| System Lifespan | Short (3–5 years for hardware/OS). | Long (15–30 years of continuous operation). |
| System Updates | Frequent, automated, often forced. | Rare; requires scheduled, manual downtime. |
| Performance Needs | Flexible (jitter/latency is manageable). | Deterministic (real-time, microsecond precision). |
| Connectivity | Standard (Internet-exposed, cloud-ready). | Historically isolated; now increasingly networked. |
| Typical Hardware | Servers, PCs, Cloud, Mobile, Networking. | PLCs, RTUs, Sensors, Actuators, HMIs. |
| Failure Consequence | Loss of data, financial/reputational damage. | Physical damage, environmental harm, loss of life. |
![\"IT](\"https://hoanlk.com/wp-content/uploads/2023/04/itvsot.png\")
\nPhysical and Logical\nPhysical Assets are tangible hardware devices used in industrial environments; often includes assets like workstation, server, n/w switch, PLC, sensors, actuators, or broadly anything that uses a micro-controller or a microprocessor.Logical Assets are those assets that reside on the physical asset; such as process graphic, database, logic program, firewall rule, firmware, etc.\n\nSummary,
\n
\nHardware = Physical Asset and
\nSoftware/Data/Config = Logical Asset
We will look into two primary ones for now -
\n\n\nBut why we need SCADA in the first place?\n
\n
Before SCADA, industries with spread-out assets (like power lines or pipelines) relied on manual monitoring. People had to physically travel to remote sites to read gauges and operate equipment. This was slow, expensive, dangerous, and inefficient.
\nSCADA was developed to enable remote monitoring and supervisory control from a central location, reducing the need for on-site personnel.
\n\nBut why we need DCS in first place?\n
\n
Large process plants (refineries, chemical plants) had thousands of control loops. Traditional centralized control using a centralized system was risky as if the central computer failed, the whole plant could shut down dangerously.\n
DCS was created to distribute control across many processors so that failure in one area doesn’t stop the entire plant. It also made complex, continuous automation easier and safer.
| Aspect | SCADA (Supervisory Control and Data Acquisition) | DCS (Distributed Control System) |
|---|---|---|
| Primary Purpose | Monitoring and supervisory control of geographically distributed systems | Precise, continuous, real-time process control within a plant |
| Geographic Scope | Wide-area operations spanning hundreds of kilometers | Single facility, plant, or industrial site |
| Control Speed | Relatively slower response (seconds to minutes) | Extremely fast response (milliseconds) |
| Control Style | Mostly supervisory or open-loop control | Closed-loop automatic process control |
| Number of I/O Points | Thousands of distributed I/O points | Tens of thousands of highly dense I/O points |
| Redundancy Level | Moderate to high redundancy for reliability | Very high redundancy for safety and uninterrupted operation |
| Typical Industries | Utilities, power transmission, water distribution, pipelines, railways, oil & gas transmission | Refineries, chemical plants, power generation, pharmaceuticals, pulp & paper industries |
| Typical Devices Used | RTUs, PLCs, master stations, communication networks, HMI systems | Distributed controllers, I/O modules, engineering stations, redundant servers |
| Communication Focus | Long-distance communication over WAN, radio, fiber, or satellite | High-speed local communication within plant networks |
| Risk if System Fails | Loss of monitoring visibility and delayed operator response | Potential plant shutdown, production loss, or major safety incidents |
| Scalability | Highly scalable across remote locations | Scalable mainly within a single industrial process facility |
| System Architecture | Centralized supervisory architecture with remote field devices | Distributed intelligence across multiple controllers |
| Data Handling | Event-driven data collection and monitoring | Continuous real-time process data handling |
| Cost | Generally lower implementation and maintenance cost | Higher cost due to redundancy, integration, and precision control |
\n\nIn today's world, lines between DCS and SCADA have almost blurred, nowadays we take a hybrid systems approach;\n
\n
A large facility has DCS for precise control inside the plant while SCADA system sits on top to monitor the entire facility or multiple facilities from a central control room.
Field components are the physical devices and systems deployed in industrial environments that directly interface with processes, equipment, and infrastructure to enable monitoring, control, and automation. These form the backbone of any ICS architecture.
\n![\"PLC](\"https://upload.wikimedia.org/wikipedia/commons/5/5a/Programmable_logic_controller.jpg\")
\n![\"Remote](\"https://upload.wikimedia.org/wikipedia/commons/d/d0/Remote_Terminal_Unit_Modular.jpg\")
\n![\"Intelligent](\"https://5.imimg.com/data5/VT/NA/UC/SELLER-22256257/process-bus-numerical-relay-siemens-500x500.jpg\")
\n![\"Industrial](\"https://static.blikai.com/prod/20240709/image%20(20).webp\")
\nSystem operations describe how ICS components interact, execute control logic, respond to process changes, and maintain operational continuity.
\nContinuous Process Control: Maintains a process variable at a constant target value over time (e.g., maintaining reactor temperature at 150°C).
\nDiscrete/Batch Process Control: Executes a series of sequential operations to produce a product or complete a task (e.g., pharmaceutical batch processing, filling bottles, assembly steps).
\nHybrid Control: Combines continuous and discrete elements (e.g., a chemical plant that continuously controls temperature while performing discrete batch transitions).
\nNegative Feedback: Output of a system is fed back and compared against input; deviations trigger corrective actions to restore equilibrium.
\nPositive Feedback: Output reinforces the input, causing the system to diverge further from equilibrium.
\nProcess Management in ICS refers to the systematic approach to designing, monitoring, optimizing, and maintaining industrial processes to ensure safety, efficiency, quality, and compliance.
\nKey Components:
\nProcess Design & Documentation: Engineering specifications, process flow diagrams (PFDs), piping & instrumentation diagrams (P&IDs) that define how a process should operate.
\nStandard Operating Procedures (SOPs): Written procedures that operators must follow during normal operations, startups, shutdowns, and emergency situations.
\nPerformance Monitoring: Continuous tracking of KPIs such as throughput, energy efficiency, product quality, asset utilization, and safety metrics.
\nPreventive & Predictive Maintenance: Scheduled maintenance based on equipment age/hours (preventive) or equipment condition data/anomalies (predictive) to minimize unexpected failures.
\nChange Management: Formal processes to evaluate, approve, test, and implement changes to process logic, equipment, or procedures to minimize risk of unintended consequences.
\nRegulatory Compliance & Auditing: Ensuring operations meet industry standards (IEC 61508, IEC 61511, NIST, NERC-CIP, EPA, FDA) and conducting regular audits and inspections.
\n\n\nWhy Process Management Matters:
\n
\nIndustrial processes involve significant capital investment, safety risks, and regulatory obligations. Uncontrolled or poorly managed processes lead to equipment failures, safety incidents, environmental violations, production losses, and financial penalties. Structured process management minimizes these risks while optimizing output.
Safety Instrumented Systems are specialized, independent control systems designed to automatically detect hazardous conditions and execute fail-safe actions to prevent accidents, equipment damage, or environmental harm.
\nKey Characteristics:
\nCommon SIS Applications:
\n![\"Safety](\"https://www.methodfs.com/images/pages/ls-lop.png\")
\n\n\nWhy SIS is Critical:
\n
\nMain control systems can fail or be compromised. SIS exists as a final, independent layer of protection to prevent catastrophic events—explosions, toxic releases, loss of life. It's not optional; it's mandated by safety standards in high-risk industries.
Smart Grid is a modernized, digitally integrated electrical grid that uses advanced sensors, communication networks, and automation to optimize the generation, distribution, and consumption of electricity in real-time.
\nComponents:
\n![\"Smart](\"https://i0.wp.com/semiengineering.com/wp-content/uploads/2015/06/con-edison.jpg\")
\nBenefits:
\n\n\nWhy Smart Grid Matters:
\n
\nTraditional electrical grids are centralized, reactive (responding after faults occur), and inflexible. Smart grids are distributed, predictive (detecting issues before they escalate), and adaptive. As renewable energy, electrification of transport, and climate concerns intensify, smart grids are essential to meeting future energy demands safely and sustainably.
Routable Networks:
\nNonroutable Networks:
\nSecurity Zones:
\nEnclaves:
\nNetwork Perimeters:
\nElectrical Security Perimeters (ESP):
\nReality: USB devices, wireless access, and contractors can bypass air gaps. Physical separation helps but isn't a complete security strategy.
\nReality: Compensating controls (segmentation, firewalls, monitoring) can provide strong security without traditional patching. Defense-in-depth works in ICS.
\nReality: Both IT and operations must collaborate. Operations understands risk tolerance and process constraints; IT provides technical tools.
\nReality: Enterprise tools often cause unacceptable latency or fail on industrial protocols. ICS requires purpose-built solutions respecting Availability > Confidentiality priority.
\n\n", "url": "https://haxnation.github.io/blog/introduction-to-ics-ot-security", "title": "Introduction to ICS/OT Security", "summary": "An introduction to Industrial Control Systems (ICS) and Operational Technology (OT) security, covering fundamental concepts, differences between IT and OT environments, and why industrial cybersecurity matters.\n", "date_modified": "2026-05-25T08:00:00.000Z", "author": { "name": "Param Jasani", "url": "https://github.com/param-jasani" }, "tags": [ "ICS", "OT", "SCADA", "DCS", "industrial-security", "critical-infrastructure" ] }, { "id": "https://haxnation.github.io/blog/welcome-to-Haxnation-blog", "content_html": "Key Takeaway: Industrial security is distinct from enterprise security. Success requires collaboration, acknowledgment of constraints, and purpose-built solutions.
\n
We're thrilled to launch the Haxnation community blog — a space for insights, research, tutorials, and stories from our growing community.
\nEvery blog post goes through a review process to maintain quality and security. Here's the flow:
\nblog/<your-github-username>/mainCheck out the Contributing Guide for full details.
\nFollow along at Haxnation.org.
\nHappy hacking ⚡
", "url": "https://haxnation.github.io/blog/welcome-to-Haxnation-blog", "title": "Welcome to the Haxnation Blog", "summary": "The official Haxnation community blog is live! Learn about what we'll be writing about and how you can contribute your own posts.\n", "date_modified": "2026-05-23T12:00:00.000Z", "author": { "name": "Haxnation", "url": "https://github.com/haxnation" }, "tags": [ "announcement", "Haxnation", "community" ] } ] }