Arbaaz Jamadar: Cloud & Application Security Engineer

About Me

I’m a cybersecurity engineer working at the intersection of cloud security, application security, and security operations. My path has run through both sides of the wire - starting in offensive security and pentesting, moving into SOC engineering and incident response automation, and now focused on building security into cloud systems rather than chasing it after the fact.

What I keep coming back to: offensive knowledge informing defensive architecture. The patterns that make a system breakable are the same patterns you have to design out when you build it. Every CTF I solve and every vulnerability I chain becomes a list of things I refuse to ship.

The case studies below are a mix of production work, deep technical projects, competitive CTF chains, and a few personal stories that explain how I actually operate.

How I Work

• Production first, theory second. I’d rather ship a real EKS cluster with imperfect observability than a perfect architecture diagram with no running code.
• Measure security as a chain, not a checklist. A 95%-coverage control matrix can still leave the chain that owns you.
• Automate the deterministic, gate the irreversible. SOAR is a force multiplier when you draw the line correctly, and a self-inflicted incident when you don’t.
• Reports are products. A finding nobody fixes is a paragraph, not a finding. Audiences matter; format matters.
• Trust the methodology when intuition runs out. The breakthroughs come from stepping back to first principles, not from pushing harder on the wrong thread.

Skills

Cloud Security (AWS). IAM, KMS, IRSA / Pod Identity, VPC design and segmentation, Security Groups, ACM, AWS Private CA, GuardDuty, CloudTrail, CloudWatch / Container Insights, Secrets Manager, ALB, Route 53, EKS, ECR, EC2, S3, Lambda, SNS, VPC Endpoints.

Cloud Security (Azure). Entra ID, Graph API, OAuth2 client credentials abuse, guest access abuse, Azure Blob exfiltration.

Application & Offensive Security. OWASP Top 10, Active Directory attack chains, web exploitation, Linux/Windows privilege escalation, container escape, Kubernetes exploitation, SSRF, command injection, SQL injection, file upload bypass, NTLM relay, RBCD abuse, constrained/unconstrained delegation, Kerberoasting, Golden Ticket, WiFi attacks.

Defensive Security & SecOps. SIEM, log analysis (ELK / OpenSearch), threat modeling (STRIDE, PASTA), DFIR, malware analysis and sandboxing (Cuckoo), incident response (MITRE ATT&CK, Cyber Kill Chain), detection engineering with Prometheus + Alertmanager, Falco, kube-bench, kube-hunter, Trivy.

DevSecOps & DevOps. GitHub Actions, Jenkins, ArgoCD, SonarQube, Trivy, FOSSA, OSSF Scorecard, Docker, Kubernetes, Helm, Terraform, Prometheus, Grafana, OpenTelemetry, Jaeger.

Languages & Tools. Python, Bash, Go, Rust, C, PowerShell. Burp Suite, Nmap, Metasploit, BloodHound, BloodyAD, Responder, CrackMapExec.

Certifications. OSCP / OSCP+ · AWS Certified Security – Specialty · AWS Certified Solutions Architect – Associate · AWS Certified Cloud Practitioner · eJPT · CompTIA Security+.

Competitive. Wiz Cloud Security Championship - Rank 18 globally · Amazon AppSec CTF 2025 - Rank 4 globally, qualified for Austin Finals.

Selected Case Studies

1. Production-Grade EKS with Full DevSecOps Gating

Independent project · 2025 · github.com/arbaaz29/eks_terraform

The OpenTelemetry demo is the microservices stack everyone uses for tutorials and almost no one actually deploys to production. I wanted to bridge that gap - take a real-world multi-service application and make it production-defensible across security, scalability, cost, and observability.

Goal

Build an EKS deployment that could survive a real cloud security review. The bar I set: zero plaintext secrets, no hardcoded IAM, encrypted at rest with customer-managed keys, vulnerability gating in CI, observability that pages on real failure conditions, and a tested rollback path.

Approach

I built it in four phases.

Foundational infrastructure. EC2 + Docker Compose validation first to de-risk the application behavior before paying the EKS complexity tax. Then EKS with a public/private subnet split, autoscaling 1→3 nodes, spot instances scoped to stateless workloads. IRSA / Pod Identity for workload-level IAM so no pod inherits node-level credentials. KMS encryption with customer-managed keys for EBS and Secrets Manager. ALB Ingress Controller with TLS termination, VPC-CNI, EBS-CSI, CloudWatch Container Insights for visibility.

Helm-based deployment. Packaged everything into versioned Helm charts with namespace isolation. Tested upgrade and rollback paths (helm rollback) - the rollback test is the one most teams skip until the day they need it.

Observability and alerting. kube-prometheus-stack (Prometheus + Alertmanager + kube-state-metrics). Custom alert rule on kube_pod_container_status_restarts_total to catch CrashLoopBackOff, paged via Gmail SMTP. The point wasn’t production-grade routing; the point was that the alert fired.

DevSecOps CI/CD. GitHub Actions: checkout → build → Trivy scan with HIGH/CRITICAL set to fail the build → ECR push → manifest patching → kubectl apply → automated rollback on failure via kubectl rollout undo. Layered FOSSA for license + OSS vulnerability scanning, OSSF Scorecard for repo health, and Gradle Wrapper validation. Secrets via GitHub Secrets, never in repo.

Outcome

End-to-end production-grade EKS deployment. Zero plaintext secrets. IRSA across the board. Rollback verified. Vulnerability gating in CI that actually fails builds. Public artifact, documented architecture, repeatable IaC.

What I learned

The gap I keep seeing in real teams is the gap between “Trivy is in my pipeline” and “Trivy fails builds for HIGH/CRITICAL and we deal with the noise.” Most teams add scanners and then mute them. The hard, valuable work is tuning to a level where the team trusts the gate enough to leave it on. That requires an exception process with expiry dates, not a config setting.

2. Threat Modeling at the API Layer (STRIDE + PASTA, mapped to NIST CSF)

Cyber Security Analyst, Chicago EAC · 2025–present

When I joined, the application architecture had internal and external API endpoints with no formal threat model. Security controls were applied reactively - “we’ll add validation when we see an attack.” Three endpoints were unnecessarily exposed externally; nobody had asked whether they needed to be.

Goal

Formalize threat modeling, identify the actual attack surface, prioritize remediation by exploitability and business impact, and bake it into the team’s process so it didn’t die after the first round.

Approach

I ran five threat modeling sessions with engineering and product.

STRIDE for per-endpoint analysis - Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege. Strong at catching mechanical issues.

PASTA layered on top for the risk-weighted, business-impact view. STRIDE will tell you an endpoint can be DoS’d; PASTA tells you whether it matters.

Every finding mapped to NIST CSF categories so remediation priorities were defensible to non-security stakeholders. For incident response work in the same role, I used MITRE ATT&CK and the Cyber Kill Chain as the frameworks for playbook authoring - the language teams already speak, not a parallel taxonomy.

Prioritized fixes by exploitability × business impact, not severity score alone. Applied controls - input validation, rate limiting, authentication enforcement - on the surviving endpoints. Re-routed two of the three external endpoints through internal-only gateways.

Outcome

• 67% reduction in external attack surface (3 → 1 endpoint)
• 2 confirmed injection / authentication weaknesses remediated
• Threat modeling now part of the design review process - engineers send design docs in advance because the sessions created shared vocabulary

What I learned

STRIDE and PASTA aren’t competitors - they answer different questions. STRIDE caught mechanical issues PASTA missed; PASTA caught a business-logic flaw STRIDE didn’t have a category for. Running both feels redundant on day one and obviously correct by week two.

The bigger lesson, though: the most valuable output of threat modeling wasn’t the findings. It was the conversations. Once a team has shared vocabulary for attacks, the next quarter of design reviews gets noticeably better without anyone running another formal session.

3. SOC Detection Engineering - Cutting False Positives by 30%

Cloud Engineer (Cloud Security Focus), KIT College of Engineering · 2022–2023

The IT/SOC was drowning in alerts. Analysts were ignoring large swaths of the queue because pattern recognition told them most were noise. That’s the worst possible state for a SOC - alert fatigue isn’t an inconvenience, it’s a security risk because real threats hide in the noise.

Goal

Reduce false positive volume without missing real threats. The trap is over-tuning - every false positive you suppress is a potential miss.

Approach

I pulled thirty days of historical alerts, classified them by alert family, and built a noise score per rule (false positive rate × volume). The top five rules were generating more than 60% of all alerts.

For each, I baselined normal behavior - what does this user, host, or service legitimately do? - then re-tuned thresholds and added correlation logic so single events stopped paging. Only patterns or threshold-crossings did. Replaced “alert on failed login” with “alert on N failed logins from M sources within T minutes followed by success.”

Eliminated duplicate alerts firing from both Splunk and ELK on the same source data.

Outcome

• 30% reduction in false positive alert volume
• True positive detection rate held steady, verified by replay testing against known incidents
• SOC analysts started actually working the queue again - and started flagging tuning suggestions of their own, which was the real sign the cultural change had landed

What I learned

The instinct when you see a noisy rule is to delete it. The right move is almost always to correlate it - single events are noisy because real attacks rarely look like single events. The other lesson: I should have measured analyst trust at the start, not just alert volume. Volume metrics were the easy ones; the trust shift was the one that actually mattered.

4. Incident Response Automation - 6 Hours to 1 Hour Per Week

Cloud Engineer (Cloud Security Focus), KIT College of Engineering · 2022–2023

We had documented IR playbooks. They were Word documents nobody followed because the manual steps took thirty minutes per alert. Common, repetitive incidents were eating roughly six hours of analyst time per week - six hours that wasn’t being spent on real threat hunting.

Goal

Automate the deterministic parts of IR so humans could spend their time on the parts that need judgment.

Approach

Inventoried the top five alert types by volume: brute force lockouts, credential exposure, suspicious IAM key usage, GuardDuty findings, public S3 misconfiguration.

Built AWS Lambda functions triggered by EventBridge rules for each. Each Lambda did the deterministic work: enrich the IOC (look up IP reputation, check user history, pull related logs), open a structured ticket, post to the SOC channel.

For safe containment actions - revoke session, rotate key, block IP at WAF - I automated the preparation but gated execution behind a human approval click. The Lambda queued the action and notified on-call; one tap executed.

For destructive actions - terminate instance, delete user - I never automated execution. Always required human review.

Outcome

• 83% reduction in weekly remediation time (6h → 1h)
• 20% reduction in alert noise (auto-closed obvious-false-positive alerts after enrichment, e.g., known scanners)
• Analysts redirected the recovered hours to threat hunting, which surfaced two real incidents in the next quarter

What I learned

SOAR is sold as “automate everything.” That’s the failure mode. The right model is “automate the deterministic, gate the irreversible.” I made one mistake early - auto-disabling user accounts on suspected credential exposure. The first real-world trigger fired on a VIP user account during business hours. After that I added human gates for any user-impacting action, full stop.

Bias toward speed almost cost me trust with the team. Trust is harder to rebuild than alerts are to tune.

5. Cloud-Native Private PKI on AWS

Independent project · December 2025

Cloud workloads needed TLS certificates for service-to-service auth and internal endpoints. The default workflow was someone running openssl req on a laptop - no audit trail, no expiry tracking, no rotation, and the Root CA private key in whatever directory the engineer happened to be working in.

Goal

Build a managed PKI on AWS that minimized Root CA exposure, automated cert lifecycle, and was auditable end-to-end.

Approach

A three-tier trust hierarchy - Root → Intermediate → End-Entity - so the Root CA can be offline-able and only signs the Intermediate. Day-to-day issuance happens at the Intermediate, which limits blast radius if it’s compromised.

AWS Private CA for the hierarchy and ACM for end-entity issuance and renewal automation. HTTPS-only enforced via TLS termination at ALB, with cert auto-rotation through ACM. Internal DNS through Route 53 private zones so naming was consistent and resolvable inside the VPC only.

CloudTrail logging for every CA operation - issuance, revocation, and config changes - so the entire lifecycle is auditable. Cross-account CA sharing via AWS RAM was scoped on the roadmap.

Outcome

Eliminated manual OpenSSL workflows. Cert renewal is hands-off. Audit-ready: every issuance has a CloudTrail event. Compliance posture aligned with enterprise PKI governance standards.

What I learned

PKI is one of those areas where doing it badly is worse than not doing it at all. A “kind-of working” PKI gives a false sense of security and people stop questioning trust. I learned to over-document the trust assumptions - every cert has a documented use case, owner, and revocation plan. The technical work was the easier half.

6. Shift-Left CI/CD Pipeline (DockFast)

Independent project · February 2025 · projects.arbaazjamadar.com/dockfast

Most CI/CD pipelines treat security as a final pre-prod gate, which is the worst place to find vulnerabilities - vulnerabilities found at deploy time cost roughly 100x more to fix than at code time. I wanted to demonstrate a shift-left model where security finds the bug before the build artifact even exists.

Goal

Build a GitOps-style pipeline where every stage has a security check, the deploy is declarative so drift is detected, and runtime observability flags anomalies post-deploy.

Approach

• Jenkins for build orchestration with quality gates per stage.
• SonarQube SAST at code level - fails the build on critical findings, not warnings.
• Trivy for image scanning before push to registry - fail on HIGH/CRITICAL with a documented exception process.
• ArgoCD for declarative Kubernetes deploy - Git is the source of truth; drift triggers reconciliation or alerts.
• Prometheus + Grafana for runtime metrics, with dashboards for anomaly detection (request rate spikes, error rate, latency outliers).

Outcome

• 98% compliance against the in-scope security checklist
• 100% of critical vulnerabilities blocked from production
• Deploy time stayed under 10 minutes despite the additional gates - tuning the scan caches mattered

What I learned

Shift-left is sold as “find bugs earlier” but the real win is cultural - when developers see SAST findings in their PR before code review, security stops being “the team that says no” and starts being feedback. The biggest pushback was on Trivy noise; the answer wasn’t to disable it, it was to invest in the ignore-list workflow with expiry dates so it didn’t accumulate forever.

Offensive Security & Research

7. Container Escape Chain - Wiz Cloud Security Championship “Contain Me If You Can”

Wiz CSC, Rank 18 globally · August 2025

A hardened-looking container with multiple defensive layers. Goal: full host breakout. The challenge wasn’t any single step - most of these primitives are well-known. The challenge was seeing the chain.

The chain.

1. tcpdump on the internal network - discovered unencrypted PostgreSQL traffic.
2. Credential capture - the unencrypted PostgreSQL session leaked DB credentials in the auth handshake.
3. PostgreSQL RCE via COPY FROM PROGRAM - once authenticated as a privileged DB user, abused PostgreSQL’s COPY FROM PROGRAM directive to gain code execution as the postgres user inside the container.
4. Container privilege escalation via sudo NOPASSWD - postgres had sudo NOPASSWD for an unintended binary, escalating to root inside the container.
5. Host breakout via /proc/sys/kernel/core_pattern - the container ran with sufficient privilege to write to /proc/sys/kernel/core_pattern. Set it to a malicious binary, triggered a core dump, kernel executed the payload as root on the host.

Each layer looked individually defensible. The unencrypted internal traffic (“it’s on the internal network so it’s fine”) + the sudo NOPASSWD on a “harmless” binary + the /proc write capability - none catastrophic alone, but the chain was. A control matrix can show 95% coverage and still leave the chain that owns you. That’s the lesson I take into every defensive design review.

8. AWS Exploitation Chain - Wiz Cloud Security Championship “Perimeter Leak”

Wiz CSC, Rank 18 globally · August 2025

Exposed AWS environment with a proxy in front. Get from outside the perimeter to data exfiltration without setting off the obvious tripwires.

The chain.

1. Proxy misconfiguration - front proxy was forwarding arbitrary internal hostnames. Step zero of an SSRF.
2. SSRF to IMDS - pivoted the SSRF to hit EC2 instance metadata. The wrinkle was IMDSv2’s token-based protection, but because the proxy forwarded headers, the SSRF could still complete the token request flow and retrieve credentials.
3. IAM credential extraction - pulled instance role credentials from IMDS.
4. StringLike IAM policy bypass - the role’s policy used StringLike with a wildcard pattern instead of StringEquals. The intent was to scope access to specific resources. The result was broader access than the author intended.
5. SNS topic exfiltration - used the over-broad permissions to publish data to an SNS topic that egressed to an external endpoint.

The IAM lesson has stuck with me into every design review since: StringLike with wildcards is almost always a mistake. Authors reach for it because StringEquals feels too rigid; the result is over-permissive. Same energy as Resource: "*" with a “trust me, the action list is narrow” justification.

The IMDSv2 lesson is shorter: v2 is better than v1, not bulletproof. If the application can be tricked into making the v2 token request and the metadata call, the protection is gone. Hop-limit=1 cuts off most SSRF chains in practice.

9. Amazon AppSec CTF 2025 - Rank 4 Globally, Qualified for Austin Finals

Amazon AppSec CTF · September 2025

Global qualifier across cloud, web, AI/ML, and secure coding tracks. Top 16 advanced to the Austin Finals. I finished Rank 4 globally and qualified for AUS16.

The single biggest performance lever wasn’t raw skill - it was the time-box. Hard rule of 45 minutes max before forced pivot, with stuck challenges going on a “come back” list. Watching the leaderboard during the qualifier, the gap between top-10 and top-50 was almost always discipline about pivoting off stuck challenges, not technical depth. The subconscious solves problems while you’re working on something else; pushing through 90 minutes of frustration costs you 90 minutes of momentum.

Strongest results were in cloud and web - the tracks I’d built depth on through Wiz and HTB work. AI was newer territory, and the work I did there (prompt injection, model output extraction, supply-chain attacks on training data) is now part of my permanent toolkit.

10. First Pentest Engagement - CyberSapiens

Security Analyst, CyberSapiens · 2021–2022

First professional security role. Ten-plus web application pentests against client targets, with full report deliverables. I’d done CTFs but never a real engagement against a real product with real stakeholders reading the report.

Approach. OWASP Top 10 as the methodology backbone. Manual testing first, automated second - Burp Suite for proxy and manual probing, OWASP ZAP for fuzzing, Nmap for surface enumeration, Nessus for known CVE scanning, Metasploit for verified exploitation paths.

Findings across the engagements. Two medium-severity issues I’m proud of: an injection vulnerability in a search parameter (insufficient sanitization on a query field) and an authentication weakness that allowed enumeration with partial bypass. For each, full PoC documentation - request/response captures, reproduction steps, screenshots - with CVSS scoring and remediation guidance aligned to OWASP cheat sheets. Reports were structured for both technical and non-technical audiences: exec summary up front, technical detail in the appendix.

The real lesson. The first report I submitted was 40 pages of Burp output. The second was 12 pages structured for the audience. A finding nobody fixes isn’t a finding, it’s a paragraph. Reports are products. Audiences matter.

This engagement also planted what became my career thesis. I wanted to prevent the bugs I was finding, not just keep finding them. That’s why I moved into cloud and AppSec architecture.

Personal Stories

11. The OSCP Eleventh Hour

OSCP, first attempt, 100 / 100 · January 2026

The OSCP exam is 24 hours. 100 points to perfect, 70 to pass. Three months of structured prep going in, plenty of confidence.

The first ten hours, I got nothing. Zero machines. Every methodology checkpoint I’d practiced - full enumeration, vulnerability research, exploit chaining, privilege escalation paths - turned up dead ends. I started doubting whether I was looking at the wrong thing entirely.

At hour ten, I forced myself to stop and walk away for thirty minutes. No laptop. No notebook. Coffee, walk around the apartment. I’d been re-running the same enumeration in slightly different shapes for two hours and my pattern recognition had collapsed.

I came back and re-read my own methodology checklist end to end - the document I’d built specifically for moments where intuition had failed me. Picked one specific machine and started over from enumeration with fresh eyes and zero preconceptions. Found the foothold I’d been missing. It was a service version detail I’d dismissed earlier as a known dead end. Wasn’t.

Once one machine fell, the rest followed in the next five hours. Solved everything. 100 / 100 on first attempt.

The instinct when stuck is to push harder. That was wrong. The breakthrough came from stepping back and trusting the methodology - the methodology I’d specifically built for moments where intuition had run out. The thirty-minute walk was the highest-leverage action of the entire exam.

I’ve used the same loop for every hard problem since: walk away, return to the documented method, restart from primitives.

Full writeup: How I Passed OSCP on First Attempt with 100 Points (3 Months Prep)

12. Mentoring 30+ in the HTB and Wiz Communities

After publishing CTF writeups and ranking on HTB and Wiz, I started getting unsolicited messages - more than thirty over time - asking for help on stuck challenges. Some were students. Some were professionals studying for certs. Some were career switchers.

The trap is spoon-feeding answers. That produces dependence, not learning. I built a Socratic mentoring loop instead.

1. “What have you tried so far?” - forces them to self-summarize, often reveals the misstep without me saying anything.
2. “What does the output of X tell you?” - points at the data they already have but aren’t reading.
3. “What’s the assumption you’re making about Y?” - surfaces the wrong mental model.
4. Only if all three failed: a small hint pointed at the right direction, not the answer.

For career switchers, roadmap advice - which certs in which order, which labs to do, how to build a portfolio.

The outcomes I’m proudest of: multiple mentees passed certifications (Security+, eJPT, OSCP). Several cleared boxes they’d been stuck on for weeks. A few placed in CTF leaderboards.

Teaching this much forced me to formalize my own methodology. When you have to articulate why you went after a particular service first, you stop doing it on instinct and start doing it on principle. That made me materially better at the work itself - the OSCP perfect score wouldn’t have happened without the structured methodology that teaching had forced me to build.

13. The Group Project That Wasn’t About Effort

A university group project. I was the lead. Two weeks in, contributions had collapsed. Standups had a couple of vocal contributors and the rest staying quiet. Deliverables were slipping and I could feel the team drifting toward the failure mode where one person finishes everything the night before.

I stopped doing public “why isn’t this done” rounds in standup. They were visibly making things worse. Set up one-on-one conversations with each non-contributing member instead. Not status check-ins - actual conversations about what was hard. “Where are you stuck?” and “What would help?” - not “Why haven’t you done X?”

The real blockers surfaced fast and were not what they’d looked like.

Language barrier for two members. The technical English in our async docs was a wall. They were reading every message twice and still missing the ask.

Unclear ownership. Tasks were assigned to “we” or “the team,” so nobody owned anything specific. Vocal contributors picked up what they wanted; everyone else didn’t know what was theirs.

Intimidation. One quiet member assumed they were behind the rest of the team, so they didn’t speak up when stuck.

I restructured. Explicit single-owner on every task, with task scope sized to confidence level. Adjusted async comms - shorter messages, no jargon, explicit asks. Used direct messages for follow-ups instead of public channels, which lowered the barrier for the quieter members to ask questions.

All members started contributing within a week. Project delivered on time. Two of them told me later it was the first group project where they’d felt like they could actually participate.

Team friction is rarely about laziness. The “why aren’t you contributing” frame is almost always wrong - it assumes people have full information and are choosing not to act. When a teammate looks disengaged, the first move is a one-on-one, not a public confrontation. Public pressure deepens the freeze; private conversation surfaces the real blocker.

Additional Work

A selection of other projects, writeups, and case studies - full details at projects.arbaazjamadar.com and writeups.arbaazjamadar.com.

• Portado - VPN-less Secure Remote Access. Cloudflare Tunnel + WAF reverse-proxy architecture replacing traditional VPN. Removed public attack surface, enforced identity-based access.
• ProxHome - Production-Style Proxmox Homelab. VLAN-segmented hypervisor environment for malware detonation, AD attack rehearsal, and CTF infrastructure. Hardened access, sinkhole DNS on the dirty VLAN.
• Cracking the Rebel Malware - Full DFIR Deep-Dive. End-to-end digital forensics: static + dynamic analysis, IOC extraction, timeline reconstruction, containment recommendations.
• E-commerce on AWS - Three-Tier Reference Architecture. Auto Scaling, multi-AZ RDS, ALB, WAF, CloudFront. Least-privilege IAM, encryption in transit and at rest via ACM + KMS, cost controls via right-sized compute and spot capacity.
• Cuckoo Sandbox Installation Guide. Full malware analysis environment, VM guest configuration, network isolation, dynamic analysis report generation.
• DockerLab - Containerized ELK Stack for Log Analysis. Reusable Dockerized ELK platform for SIEM-style log ingestion, parsing, and detection engineering training.
• Healthcare Infrastructure Security Redesign. HIPAA-aligned controls, network segmentation, access controls, encryption, monitoring, threat model, and remediation roadmap.
• Buffer Overflow Exploitation Walkthrough. Stack-based BOF: fuzzing, offset identification, bad character analysis, JMP ESP gadgets, shellcode delivery. Linux and Windows 32-bit fundamentals.
• HackTheBox Season 10 - 14 Machines Documented. Active Directory chains (RBCD abuse, constrained delegation, SPN jacking, RODC KeyList, Golden Ticket, ADIDNS), web exploitation (Hoverfly RCE, Spring Boot Actuator, Apache CXF, MSSQL linked server pivoting), Linux privesc (CVE-2025-6018/6019, PAM abuse, SUID misconfigurations), .NET reverse engineering, NTLM relay, WiFi attacks (WPA-PSK, WPA-PEAP, evil-twin, EAPHammer, aircrack-ng).
• CVE Analysis Writeups. Hands-on exploitation and mitigation walkthroughs for CVE-2025-6018/6019 (udisks2/libblockdev), CVE-2025-9074 (Docker Desktop escape), CVE-2022-3294 (Kubernetes nodes/proxy authorization bypass), CVE-2023-37679/43208 (Mirth Connect unauthenticated RCE chain), and others.

Get in Touch

Open to roles in Cloud Security Engineering, Application Security, and Security Operations - particularly where offensive knowledge informs defensive architecture and where AWS/Kubernetes security is front-and-center.

• Email: arbazij@gmail.com
• LinkedIn: linkedin.com/in/arbaazz
• Portfolio: arbaazjamadar.com
• GitHub: github.com/arbaaz29