Video summary

Default Creds, a Fresh CVE, and an LLM: How Armadin Got RCE on a Client - Hackers On The Rocks

Main summary

Key takeaways

News and Commentary

Overview

The episode is framed as a “tales from the field” war story about how an Armadin red teamer exploited a real-world vulnerability in a client environment, and how AI-assisted methods sped up the vulnerability research workflow.


Workflow and discovery (starting from a large external attack surface)

  • Guest role: James works on Armadin’s network-side red team activities—conducting external reconnaissance, then attempting to breach toward internal networks.
  • Client environment: The target had a large Azure/cloud footprint with many externally reachable systems.
  • Initial identification: Using automated reconnaissance and lightweight scanning (e.g., Nuclei templates), James identified an exposed Sonatype Nexus repository instance.
  • Initial signal: Nexus was reachable and appeared to have default credentials.
  • Why it wasn’t obvious at first: The interface contained no obvious interesting content, leading to deeper investigation.

The vulnerability and what was mischaracterized

  • Correct vulnerability: James determined the Nexus version was vulnerable to CVE-2026-3199.
  • How it was described in the episode: The CVE was framed as involving insecure deserialization leading to RCE, specifically tied to a task/type identifier field.
  • What James found instead: During analysis, he believed the initial write-up was likely incorrect—it was not insecure deserialization in the way it was described.
  • The actual issue: An authorization / mass-assignment-style problem:
    • Nexus supports managing “tasks” (including metadata).
    • By manipulating a task’s type ID, an attacker could switch the task to a type that enables Groovy scripting execution, even if scripting was intended to be disabled.
    • With Groovy execution, it effectively becomes RCE-as-a-service, enabling command execution on the host.

Escalation to impact

After obtaining code execution, the attacker could:

  • Break out from the web application context to the broader host.
  • Perform typical post-exploitation actions such as internal enumeration, aligned with the red team goal of moving from perimeter access toward internal access.

How AI-assisted methods accelerated the timeline

A key theme: without AI assistance, finding and confirming the exact exploit path would likely take much longer—especially when:

  • there are thousands of hosts to triage, and
  • patch analysis involves large, messy changes.

James describes two major accelerators:

  1. LLM-assisted patch diffing

    • Rather than manually reading vast Java/Groovy code and scanning hundreds of changed files, he used an LLM to compare vulnerable vs. fixed versions.
    • The fix appeared to relate to only a small number of lines (about 3–4), despite the overall patch touching a large surface area.
  2. LLM usage as a “coverage multiplier”

    • Armadin uses automation for reproducible discovery steps (enumeration, scanning, screenshot review, etc.).
    • Then it uses LLMs/agents for reasoning across large or unstructured outputs, such as interpreting hundreds of screenshots or summarizing diffs quickly.
    • This enables parallelization: while James investigated one bug, other agents pursued other leads.

Time savings estimate

  • For an experienced researcher (already familiar with Nexus/Groovy/Java): exploitation could take hours to about a day.
  • For James specifically (newer to Nexus): it could have taken several days or half a week or more without the AI-accelerated approach.
  • He suggests that pinpointing the relevant change may have taken about ~30 minutes using the described method.

Guidance for customers hiring red teams with AI

Near the end, the episode shifts to advice for selecting a red team provider:

  • Use a “proof of value” / bake-off approach
    • Give the same target environment to multiple vendors and compare results.
    • Judge based on actual impact (e.g., finding RCE and demonstrating real exploitation), not vague risk descriptions.
  • Check references and prior outcomes
    • Ask for references and evidence that the firm is using modern methods (including AI), rather than producing generic reports.

Main takeaway

AI-enabled workflows—paired with skilled operators—can significantly shorten the path from “vulnerable version found” to “real exploitation and demonstrated impact,” even when:

  • the vulnerability write-up is misleading,
  • the codebase changes are large, and
  • the tester’s initial platform expertise is limited.

Presenters / contributors

  • James Dlin (guest, Armadin red teamer)
  • Host(s): podcast hosts of Hackers On The Rocks (names not provided in the subtitles)

Rate this summary

Your feedback will help improve summaries.

Improve this summary

Reprocess with a stronger model when the summary feels incomplete or inaccurate.

Pro

Translate summary in another language

Pro

Ask questions to this video

Chat for follow-up questions, clarifications, and source-backed answers.

Coming soon

Share this summary

Original video