“Next Exploit Opportunities”: How a Threat Actor Used AI to Help Plan and Execute Multiple Types of Cybercrime Activities

Executive Summary

“Can you find about like what scam or thing they done in past like spoofing calls or somthing [sic],” the threat actor typed. The conversation was with one of several AI assistants that the actor was using to get advice on planning and executing a variety of cybercrime activities.

Our visibility into this specific actor's operational environment gives us unique insights into exactly how threat actors are building, testing and executing agentic attacks across multiple campaign types.

Unit 42’s investigation into the actor’s operational environment and activities makes two things clear:

• The attacker used basic tooling and relied on AI-generated scripts and reconnaissance reports, suggesting they didn’t have the skills these activities would have required before the advent of readily available AI tools.
• Despite some apparent bumbling, the actor had an impact, attacking a number of targets in India, including universities. The actor recovered thousands of records revealing personal information and mapped multiple organizations’ attack surfaces.

The attacker’s conversations with jailbroken AI tools included getting step by step advice on how to set up a fraudulent Voice over IP (VoIP) operation. One assistant “helpfully” generated a document including a “NEXT EXPLOIT OPPORTUNITIES” section, outlining planned followup attacks.

Unit 42 identified and investigated this threat actor's operational environment. There, we determined that they had weaponized an AI assistant across several types of cybercrime, including:

• Credential theft and data exfiltration
• VoIP telecommunications fraud
• Wi-Fi password cracking
• Cryptocurrency reconnaissance
• Command-and-control (C2) operations

An actor operating under the handle BUGSTER configured the Hermes Agent framework with DeepSeek V4 as its reasoning engine and Cursor integrated development environment (IDE) as a secondary tool, both with safety controls disabled. The actor ran an AI-generated brute-force campaign against an Indian university’s website. The actor also achieved a confirmed intrusion against a second university, where they exfiltrated a database of more than 5,200 records, including personally identifiable information (PII) on students.

The actor also built specialized AI bot profiles to acquire VoIP fraud expertise through conversation and maintained automated pipelines for Wi-Fi password cracking and cryptocurrency whale reconnaissance (i.e., identifying large cryptocurrency holders). Notably, the Wi-Fi cracking capability requires close physical proximity to the target, indicating the actor had local access to the targeted locations.

Multiple, unrelated actors are independently adopting the same Hermes + DeepSeek combination. This suggests we may be witnessing an increasingly prevalent toolchain of choice for cybercriminals adopting AI-enabled capabilities. We assess a key driver is low safety friction at low cost: DeepSeek models are inexpensive and easy to access, and readily jailbroken with a simple system-prompt override.

Palo Alto Networks customers are better protected from the threats discussed above through the following products and services:

• Advanced URL Filtering and Advanced IP Defense
• Cortex XDR and XSIAM
• Cortex Agentic Endpoint Security
• Cortex Cloud
• Idira Privileged Access Manager (PAM)
• Idira Identity and Access Manager (IAM)
• Idira Secrets Manager

The Unit 42 AI Security Assessment and Unit 42 Frontier AI Defense service can help identify and mitigate complex AI-enabled risks.

Organizations can access tailored adversary intelligence, direct analyst consultations, and specialized exposure tracking through Unit 42 Threat Intel Services and its Deep and Dark Web Service.

If you think you might have been compromised or have an urgent matter, contact the Unit 42 Incident Response team.

Related Unit 42 Topics

AI, Credential Theft, Cryptocurrency

Technical Analysis

We identified evidence that the threat actor leveraged AI systems for a wide range of criminal activity against multiple target networks, primarily in India. The criminal activity included:

• Planning for VoIP fraud
• Credential theft targeting several organizations
• Wi-Fi password cracking
• Cryptocurrency reconnaissance
• C2 payloads

Credential Theft and Data Exfiltration

WordPress Brute Force

The actor used AI-generated reconnaissance to conduct a methodical attack against an Indian university's online education platform. The actor’s enumeration reports exhibit structured formatting (executive summaries, severity ratings, systematic endpoint categorization) consistent with AI-generated output. The attack progressed through four stages:

1. Subdomain enumeration: The actor identified 12 subdomains including the main WordPress site, a learning management system (LMS), student portal and administration dashboard
2. WordPress REST API enumeration: The actor extracted 13 active user IDs with real names via post author fields and author sitemaps, bypassing the Cloudflare Web Application Firewall (WAF) that blocked direct user endpoint access
3. Targeted brute force: A generator script produced a brute force tool with 117 usernames (derived from the enumeration) and 28 common passwords
4. Credential brute force: The actor’s tool flagged one WordPress login as valid

Figure 1 shows an excerpt from the actor's WordPress REST API enumeration report (stage 2).

Figure 1. Example of a WordPress REST API enumeration report from the activity.

Figure 2 shows output from a brute force attempt that recorded a candidate credential (stage 4).

Figure 2. Brute force tool output recording a candidate credential.

University Database Exfiltration

The actor exfiltrated a MongoDB database from a second Indian public university. The exfiltration tooling wrote a manifest alongside the dumped collections, recording the following data:

• Admin credential obtained: An administrator account with a weak password
• Exfiltrated records: Thousands of student records (diploma, undergraduate, postgraduate) and faculty records containing PII
• Infrastructure exposed: Cloud load balancing, edge routing, database services, and a third-party cloud storage service account

E-Commerce Enumeration

The actor enumerated an Indian site on a popular e-commerce platform, extracting:

• A storefront API token
• Three admin email addresses
• Two phone numbers
• Payment merchant IDs

The attack report is a suspected large language model (LLM)-generated document, including a NEXT EXPLOIT OPPORTUNITIES section outlining planned follow-up attacks.

VoIP Telecommunications Fraud

We also identified evidence that the actor was developing VoIP (Voice over IP) fraud infrastructure, using the alice Hermes profile as an AI-powered advisor. Evidence included:

• Advisory conversations
• A detailed technical knowledge base
• Carrier research

However, the absence of call logs, Session Initiation Protocol (SIP) traces or active call routing suggested the operation was still in a planning or early setup phase.

With DeepSeek V4 as the underlying model, alice provided detailed, actionable criminal methodology through conversations and a comprehensive fraud knowledge base ingested into the bot. The actor developed a planned approach following an established VoIP fraud model:

• Establish a legitimate front: Register a US limited liability company (LLC) with an employer identification number (EIN) to qualify as a telecommunications provider. The knowledge base includes detailed guidance on:
  • Forming LLCs in Wyoming or Delaware as a non-US resident
  • Obtaining an EIN without a Social Security number via the US Internal Revenue Service (IRS) fax
  • Completing Federal Communications Commission (FCC) registration
• Obtain carrier access: Contract with legitimate VoIP carriers to purchase call routing capacity (SIP trunks).
• Traffic mixing: Route approximately 70% legitimate call traffic alongside 30% fraudulent calls to stay below carrier compliance audit thresholds.
• Bypass caller ID authentication: Circumvent STIR/SHAKEN, the FCC-mandated caller identity verification framework. In the advisory conversations, alice covers bypass techniques and Calling Line Identification (CLI) spoofing.
• Monetize: Generate revenue with the 30% fraudulent traffic through toll fraud and other non-compliant routes. Least-cost routing (LCR) optimizes per-minute costs across carrier tiers.

Figure 3 shows an excerpt from an alice conversation including the actor asking and DeepSeek advising on fraud traffic ratios and carrier evasion.

Figure 3. Excerpt from the alice conversation.

The pandarouter profile handled carrier research. The excerpt below in Figure 4 illustrates how the actor used it to investigate a wholesale VoIP carrier for regulatory vulnerabilities and past fraud.

Figure 4. Using the pandarouter profile to investigate a carrier.

Other Operations

Command and Control

The threat actor’s infrastructure maintained a listening port for a Python-based C2 listener supporting Windows reverse shell connections. Supporting payloads include:

• A Base64-encoded PowerShell reverse shell delivered via VBScript
• A QubesOS VM setup script with SSH and ncat
• Multiple Windows shell variants

Wi-Fi Password Cracking

The actor developed an automated Wi-Fi password cracking process. A Linux (Kali) device the actor labeled Pi placed within range of target Wi-Fi networks captured Wi-Fi Protected Access (WPA) authentication material (PMKID or EAPOL handshakes) from nearby access points.

The server collected these hashes over an SSH tunnel and dispatched them to Vast.ai cloud GPU instances for cracking, with results automatically reported back to the actor via Discord webhooks. This technique requires physical proximity to the target networks, indicating the actor had local access to the targeted locations.

Credential Scanning Toolkit

We also identified a large Go-based credential-scanning toolkit. This toolkit scrapes webpages and extracts exposed credentials, including:

• .env values
• S3 signed URLs
• Google Cloud service account keys
• Content delivery network (CDN) API keys
• Private keys in log files

A companion Python script scrapes domain lists for scanning.

Cryptocurrency Reconnaissance

The actor scraped the top 500 ETH holders and major token holders via the DeBank API, producing intelligence files that documented 45 cryptocurrency whales with net worth figures. We assess this was likely for future targeting, but we were unable to identify any follow-on activity during this research.

Tool Design and Infrastructure

The threat actor used a single US-based server (162.243.3[.]92) to host multiple core services, including:

• The Hermes Agent framework
• A C2 listener
• A Cursor integrated development environment (IDE) proxy
• Several supporting components

Our analysis of the actor’s logs and test scripts indicates that they experimented with various LLMs, including GLM 5.2 by Zhipu AI and other models accessed through OpenRouter. Ultimately, they chose DeepSeek V4 as the backend for operations.

The actor's test scripts show repeated attempts to defeat model safety controls with a prompt-level override. Although GLM 5.2 is an open-weight model that has been reported as weakly guarded, the actor built a dedicated script to send the override to GLM 5.2 and flag refusals. This is evidence of resistance the actor worked to overcome.

The actor ultimately operationalized DeepSeek V4, consistent with the minimal safety controls observed in the Chinese-speaking activity we previously reported. Figure 5 shows an example of the system prompt the actor used to override model safety controls (from the actor's model-testing scripts, e.g., test_batch1.py).

Figure 5. Example of a system prompt to override model safety.

Table 1 summarizes the actor's AI tool configurations.

Tool	Model	Role	Safety Configuration
Hermes Agent	DeepSeek V4	Primary AI assistant, Telegram-controlled	System prompt override
Cursor IDE	Multiple models configured (Claude Opus 4.8, GPT-5.5, Composer 2.5, others)	AI-assisted code generation	Agent mode forced and permission checks bypassed via proxy environment variables; IDE sandbox set to disabled; MCP servers auto-approved

Table 1. AI tool configurations.

Figure 6 shows a flowchart that illustrates the actor's infrastructure and how the AI tools interconnect.

Figure 6. Actor infrastructure and AI tool relationships.

The Hermes Agent served as the actor's primary interface, controlled via Telegram direct messages. The actor maintained three Hermes profiles as specialized AI modes, each running as a separate Telegram bot gateway spawned from the operator's session (Table 2).

Profile	Command	Working Directory (CWD)	Description
make-good	hermes gateway run --profile make-good	/root/.hermes/profiles/make-good	General-purpose criminal assistant with safety overrides
alice	hermes gateway run --profile alice	/root/.hermes/profiles/alice	VoIP fraud advisor; covers carrier compliance evasion, STIR/SHAKEN bypass and LLC formation
pandarouter	hermes gateway run --profile pandarouter	/root/.hermes/profiles/pandarouter	VoIP route management and carrier research

Table 2. Telegram Hermes profiles.

The actor configured four additional profiles (dev, check, vuln, deploy) in a shared Telegram group. While we did not observe any chat artifacts for these profiles, the naming suggests the actor used AI to assist with development, validation, vulnerability testing and deployment automation functions.

The Cursor IDE was configured through a proxy script named cipher-proxy.sh that set environment variables to enable full agent mode and bypass its permission and sandbox controls. The configuration and the AI-generated scripts on the host shown below in Figure 7 suggest the actor used it for code development.

Figure 7. Configuration info on the host.

Attribution

We assess the actor is a financially motivated, multi-domain criminal operator with no prior reporting. The actor is English-speaking with informal, frequently broken grammar. The alice bot's stored memory describes the actor as a “gamer, OSINT, VoIP entrepreneur” claiming to hold a US LLC and EIN. Figure 8 below shows text from the pandarouter bot's stored memory, which is more candid.

Figure 8. Text from the pandarouter bot's stored memory.

Table 3 lists further attribution indicators of this actor.

Indicator	Value
Email	bugstergap@gmail.com
Display name	B U G S T E R
Cursor IDE user ID	158034011
Telegram user ID	7593151260

Table 3. Attribution indicators.

Conclusion

This case illustrates how AI lowers the skill barrier for cybercrime. The actor used basic tooling and relied on AI-generated scripts and reconnaissance reports, but still achieved notable impact. They recovered more than 5,200 PII records and mapped multiple organizations' attack surfaces. AI enabled a single actor to operate across diverse attack types (credential theft, VoIP fraud, Wi-Fi cracking, cryptocurrency targeting) that would traditionally require distinct skill sets.

The VoIP fraud planning demonstrates a particularly notable use of AI as a domain expert. With DeepSeek V4 as the underlying model, the actor's bot profiles provided detailed, actionable criminal guidance.

This guidance included specific fraud-to-clean traffic ratios, carrier audit thresholds to stay below and operational security measures to avoid detection. The model's minimal safety controls allowed it to function as an on-demand criminal advisor, enabling the actor to acquire operational expertise through conversation rather than experience.

Combining these findings with our previous reporting on a Chinese-Speaking threat actor leveraging the Hermes + DeepSeek toolchain points to growing uptake of this combination among cybercriminals.

Palo Alto Networks customers are better protected from the threats discussed above through the following products:

• Advanced URL Filtering and Advanced IP Defense identify known domains and URLs associated with this activity as malicious.
• Cortex XDR and XSIAM are designed to accurately detect the threats described in this article with the Malware Prevention Engine, and behavioral analytics to reveal the root cause to speed up investigations.
• Cortex Agentic Endpoint Security is designed to help discover every AI artifact and AI agents activity across the agentic endpoint, assess its risk, enforce prevention and runtime controls, and remediate violations.
• Cortex Cloud is designed to protect cloud posture and runtime operations against identity-driven threats by pairing static permission baselines with deep behavioral context. By embedding the functional identity baselines discussed in this research into our detection engine for both cloud VM compute and serverless agents, Cortex Cloud adds a vital layer of operational context, enabling security teams to filter out noisy false positives and decisively catch threat actors attempting to disguise their presence, alter configurations or execute anomalous operations in the environment.
• Idira Privileged Access Manager (PAM) is designed to unify privileged access across human, machine, and agentic identities to secure cloud access across multi-cloud environments. Building on proven PAM, it delivers centralized secrets management alongside modern controls like Just-in-Time access and Zero Standing Privileges. This enforces consistent least-privilege security across on-premises, cloud, and SaaS targets.
• Idira Identity and Access Manager (IAM) is designed to enable secure, unified access across human, machine, and AI identities, balancing granular control with a seamless user experience. Powered by SSO, phishing-resistant MFA, passwordless login, and enterprise password management, Idira IAM extends intelligent privilege controls and session security across the broader workforce to meet the security demands of today and tomorrow.
• Idira Secrets Manager is designed to help secure and automate API keys and webhook tokens just-in-time to eliminate hardcoded credentials and prevent exfiltration.

The Unit 42 AI Security Assessment and Unit 42 Frontier AI Defense service can help identify and mitigate complex AI-enabled risks.

Organizations can access tailored adversary intelligence, direct analyst consultations, and specialized exposure tracking through Unit 42 Threat Intel Services and its Deep and Dark Web Service.

If you think you may have been compromised or have an urgent matter, get in touch with the Unit 42 Incident Response team or call:

• North America: Toll Free: +1 (866) 486-4842 (866.4.UNIT42)
• UK: +44.20.3743.3660
• Europe and Middle East: +31.20.299.3130
• Asia: +65.6983.8730
• Japan: +81.50.1790.0200
• Australia: +61.2.4062.7950
• India: 000 800 050 45107
• South Korea: +82.080.467.8774

Palo Alto Networks has shared these findings with our fellow Cyber Threat Alliance (CTA) members. CTA members use this intelligence to rapidly deploy protections to their customers and to systematically disrupt malicious cyber actors. Learn more about the Cyber Threat Alliance.

Indicators of Compromise

• 162.243.3[.]92 - actor infrastructure
• 104.238.38[.]202 - commercial proxy server

Additional Resources

• Chinese-Speaking Threat Actor Harnesses AI Models for Autonomous Cyberattacks – Palo Alto Networks Unit 42

from Unit 42 https://ift.tt/W6D5wZs
via IFTTT

Google Chrome Adds ClickFix Warnings to Stop Users From Running Malicious Commands

Google on Tuesday said it's rolling out improved safeguards in its Chrome browser to secure users against ClickFix attacks when Enhanced Protection is enabled.

ClickFix is a popular social engineering technique in which bad actors trick users into copying and pasting malicious code directly into their computer's operating system, thereby bypassing conventional security controls.

As part of these attacks, unsuspecting users who land on legitimate-but-compromised sites or malicious ads are redirected to phishing landing pages that display fake Cloudflare or Google reCAPTCHA verification or other non-existent errors and instruct users to copy and paste a command on the Windows Run dialog (or the Mac Terminal app) to address it.

The moment a user presses the Enter key after pasting the command, it triggers a multi-stage infection chain that leads to the deployment of malware, such as information stealers or remote access trojans. In an attempt to blend in with regular activity and evade detection, the commands often make use of living-off-the-land (LotL) tools like PowerShell or cmd.exe to download next-stage payloads.

A key reason why ClickFix remains an effective initial access method is that it flips the script on traditional phishing. Instead of exploiting sophisticated vulnerabilities or getting a user to click on suspicious links, it tricks them into opening the front door themselves under the pretext of troubleshooting a commonplace issue.

"By shifting the download process out of the browser and into the terminal, attackers completely sidestep existing Chrome and Safe Browsing download protections," Google said. "To combat this technique, Chrome now detects when an Enhanced Protection user is tricked into copying suspicious commands."

If a user copies a potential ClickFix script, the clipboard payload is scrubbed of any personal information it may contain and sent to Safe Browsing for further analysis. If the security system determines the command is dangerous, Chrome displays a warning. By doing so, the idea is to prevent the attack from taking place before the user executes the malicious command.

Separately, Google is also introducing the following defenses in Chrome to tackle scams for users who enable Enhanced Protection -

• Establishing a taxonomy for Safe Browsing site warnings: Suspicious sites, which exhibit deceptive patterns commonly associated with known malicious sites, and Dangerous sites, which refer to sites that are known to be malicious and have a high risk of user harm.
• Building upon on-device large language model (LLM)-based approaches to flag tech support scams and others, such as fake antivirus and browser update scams.

"This model evaluates page content to analyze key indicators, such as the brand represented, the intent of the page, and a scam likeliness score, giving us rich threat data needed to identify deceptive sites," Google said.

"Throughout this process, Chrome minimizes the amount of data shared with the server by only analyzing page text when a site exhibits high-confidence scam indicators. And whenever page content is sent off the device, it is processed ephemerally – meaning it is never logged, retained or used to train models."

On Tuesday, Google said it's introducing Financial Services Verification in the U.S. and Canada to validate an advertiser's credentials and ensure ads come from authorized financial providers. The verification program already applies to various markets globally, including Australia, Brazil, India, Indonesia, Malaysia, New Zealand, Türkiye, and several countries in Europe.

"Under this policy, advertisers must demonstrate they are authorized by relevant regulators or recognized registries before running certain financial ads – helping prevent brand impersonation and stopping bad actors from reaching people," Google said.

"Alongside our ongoing work with financial regulators, we're working in the U.S. with the American Bankers Association to use their dedicated registry to verify authorized banks before ads can run. In Canada, we’re engaging closely with the Canadian Bankers Association as we prepare for our rollout."

Apple Blocks Identity Resolution in Safari and WebKit

The development comes as Apple revealed new privacy protections built into Safari and WebKit as part of iOS, iPadOS, macOS, and visionOS 27 releases, taking steps to block a practice called identity resolution that turns email addresses into persistent tracking identifiers.

"In this scheme, third-parties (i.e., not the website owner) invisibly collect your email address when you log in or sign up for a newsletter," Apple's WebKit team said. "They send the email address to their servers, create an opaque tracking ID permanently linked to your email address, and send that tracking ID back to the web page."

"The tracking ID is stored on the website and can from thereon be used for arbitrary purposes linked to your email address, such as building a profile of your browsing or targeting ads at you across websites. Logging out or unsubscribing from that newsletter does not remove the tracking ID or your email address stored with the third party."

Apple said the third-parties can build more data about users as they log in with their email address or fill in forms containing personal data, allowing them to create an identity graph with their name, residential address, phone number, and IP address.

To prevent this sort of cross-site tracking, Safari blocks network access to identity resolution infrastructure embedded within the web pages, effectively stopping the third party from sending the email address to their servers. The blocking, Apple said, is done at the domain level.

"It's not enough to block cross-site cookies to prevent cross-site tracking today because the tracking industry has not stopped trying to track users on the web," Apple said. "They have ushered into what they call the post cookie era and in our latest releases we have put strong protection in place."

from The Hacker News https://ift.tt/YrHLzxQ
via IFTTT

The Harness Is the Hard Part of Agentic Pentesting

An AppSec team can point an AI agent running on a general-purpose model at its own web apps with little setup. Sure, the model writes the attacks. But everything that makes those attacks safe to run against production and worth acting on afterward lives in the harness around the model. The harness is where the engineering in AI pentesting sits. The Hugging Face intrusion OpenAI disclosed in July showed what happens when that harness gives way, even inside an OpenAI evaluation built to contain the agents.

Why Each Control Takes Rigorous Engineering

Let’s take a closer look at the attack different stages and the role AI agents can take there

Scope

A pentesting agent makes thousands of decisions about where to send its next request, and the model judges each one against a rule written in plain language. A web app’s real boundary often extends past one domain through redirects and calls to outside services. Enforcing scope means code that inspects every request before it leaves, and OWASP’s 2026 guidance routes privileged actions through a deterministic policy engine that checks them at execution time, outside the model.

Credentials

Finding exposed credentials is part of what a pentest does, so the agent regularly comes across working keys outside its assignment. Which of those it may use, for what, and when a person gets involved are policy decisions that the code around the model applies on every attempt.

Prompt Injection

Every page and API response the agent reads, including hidden fields, metadata and comments a user never sees, can carry content written by anyone who can post to the app. A single product review is enough to plant malicious instructions. OWASP ranks prompt injection the top risk for LLM applications and notes that no reliable prevention exists today. The design question is not whether the model gets fooled, but how much damage it can do if and when it does. That comes down to two things: how tightly each action is constrained and which actions require further inspection and human sign-off. Neither is simple. OWASP warns that approval fatigue degrades reviewer judgement at scale, so routing everything to a human simply shifts the failure point down the line.

Proof

In October 2026, Google stopped accepting product vulnerability reports to its open-source bug bounty program after a surge in automated submissions, the majority of which it said were not valid. A finding a developer can’t reproduce is just another ticket to close. Producing one worth acting on means running the exploit, capturing what it reached, and packaging the result so anyone can replay it, all within the limits of the other controls set.

None of this is built once. Every model upgrade can change how the agent behaves, and every release changes the app whose security it tests. And around the controls sit the systems a production agent depends on, including change-triggered testing, routing findings to the developers who own the code, strictly controlling what customer data reaches a model provider, and connecting what the agent finds in the app to the rest of the environment.

Across all of it, the pattern is the same. The model reasons about what to try, and deterministic code decides what runs, records it, and stops it when needed.

How Pentera Apps Implements the Harness

This separation of reasoning and execution is how we approach building Pentera Apps. Instead of letting an AI model send requests directly into an application, Pentera Apps pairs an AI that decides what to test with a deterministic harness that controls what runs. Every action is logged and any test can be paused or stopped at any time. It's the same safety discipline Pentera has applied to production testing for nearly a decade, across thousands of global customers.

The harness also produces the proof. Every finding ships with a replayable exploit script, a CVSS 3.1 score and CWE mapping, so developers can reproduce the attack themselves instead of taking it on trust. Once the fix lands, the exact same attack can be re-run to confirm the path is closed. Tests run on demand or on a schedule, with change-triggered testing in CI/CD coming next, so validation stays inline with development.

The surrounding systems follow the same discipline. Only minimal, redacted data reaches the LLM, with zero retention and no training on customer data, and data stays in the customer’s region. Every test starts with context from reconnaissance across the customer’s attack surfaces, findings from their security stack, and live threat intelligence signals. That context lets Pentera trace an exploit in a web app be traced into network, cloud, and identity on one platform.

In agentic pentesting, the harness determines the results. Pentera Apps builds it in, so security teams get validated findings without building one themselves.

Note: This article has been expertly written and contributed by Assaf Regev, AVP Product Marketing at Pentera. Security teams can sign up for early access to Pentera Apps, Agentic Web App Pentesting.

Found this article interesting? This article is a contributed piece from one of our valued partners. Follow us on Google News, Twitter and LinkedIn to read more exclusive content we post.

from The Hacker News https://ift.tt/ClUnIYH
via IFTTT

Attackers Hijacked Over 300 Tor Exit Relays to Intercept SSH Connections

Attackers took control of more than 300 Tor exit relays in early October and used them to redirect SSH connections to servers that stole login passwords, a researcher found.

Exit relays are the last hop in a Tor circuit, where traffic leaves the network for its destination. Only a password login to an SSH server made through Tor between October 1 and 5, after accepting the interception server's host key, could have been captured.

The Tor Project began flagging relays on October 4, and by October 5, none remained in the consensus, the list of relays that Tor clients use. At the peak on October 4, the relays carrying the attacker's exit policy made up 7.46% of Tor's exit capacity, measured by consensus weight, according to an analysis of public Tor directory data posted to the tor-relays mailing list.

The researcher, who publishes as kaba, scanned all of Tor's roughly 3,000 exits on October 2 and found 333 redirecting SSH to the same 12 interception servers. The directory-data analysis counts 377 relays run by 59 operators that switched to the attacker's exit policy between October 1 and 4, which it calls "a policy match, not proof of compromise."

How the Hijacked Exits Intercepted SSH

An exit relay only carries traffic to the ports its exit policy allows. The attackers rewrote that policy in the relays' torrc configuration files to allow port 22 (the SSH port), enabling SSH on 342 relays that had blocked it. Another 24 relays that had not been exits at all became exits.

"It seems the attacker is gaining access to Linux based hosts and when these machines are running non-exits they are editing the torrc file and turning them into exits to be able to carry out the SSH attack," the Tor Project's network health team wrote in its October 5 notice to relay operators. Most of the affected relays were already exits, the directory data shows.

The same change closed the encrypted mail ports, IMAPS and POP3S, and on most relays opened the plaintext-capable ones, POP3 and IMAP.

A Tor client only picks an exit that allows the destination port, so these relays stopped carrying encrypted mail and started carrying SSH, Telnet, and, on most of them, plaintext mail. Why the encrypted mail ports were closed is not visible in the data, the analysis says.

With port 22 open, an SSH connection through one of these exits went to one of 12 interception servers instead of its destination, kaba found. When a server intercepted the connection, it presented its own host key. A user who already knew the real server's key saw OpenSSH's warning that the remote host identification had changed, and a user connecting for the first time saw the usual prompt to accept a new key.

In the October 2 scan, about a dozen exits were serving a fake host key, and the other 300 or so redirected through the same servers without altering the key.

A user who accepted the key and typed a password handed it to the interceptor. The interceptor connected to the real server, so the session worked, and every command could be watched and separately logged in with the stolen password to check for sudo and run a base64-encoded Perl installer. In kaba's honeypot, the installer took the same form as the command that put Ebury, a backdoor that hides inside OpenSSH, on one of a relay operator's servers, as described below.

A key-based SSH login could not be relayed this way. Under the SSH authentication protocol, , the client's signature includes an identifier unique to each session, so a signature made for the interceptor's session is useless against the real server. The interceptor could still accept a key login itself and show a fake shell, but it could not reach the real server with it.

A password, by contrast, travels inside the encrypted session and can be read by the server at the other end, which here was the interceptor.

Who Was Exposed, and What to Do If You Were

To be exposed, someone had to connect to an SSH server over Tor between October 1 and the afternoon of October 5, land on one of the hijacked exits, have the connection intercepted rather than passed through, accept the interceptor's host key, and log in with a password. No count of victims exists.

If you accepted an unfamiliar or changed host key over Tor in that window, treat the password you typed as stolen, change it, and check that server for the Ebury signs listed below. An OpenSSH client that accepted the key saved it in known_hosts.

The server that intercepted kaba's connection used an ED25519 key with the fingerprint SHA256:6baCZCPsl+AfQuujUS81fMEE/C7UeJ+AwjrImqmDB3E, though the other interception servers may have used different keys.

How It Was Found and Stopped

Kaba encountered the attack on the morning of October 2, when an SSH connection over Tor returned a changed-key warning. He then used exitmap, a scanning tool that the Tor Project's network health team also uses, to open an SSH connection from one of his servers to another via each exit in turn.

One end checked whether the host key was correct, and the other whether the connection originated at the exit or from an interception server. He reported the results to the health team that evening.

The health team also spotted the policy change through its own monitoring. On October 4, it contacted Zimmer, who ran the Quetzalcoatl relay family, the largest group of affected relays, and Zimmer confirmed the change was not his, asked for the relays to be marked bad, and stopped Tor on the server running them.

Directory authorities began voting the BadExit and MiddleOnly flags on affected relays at 18:00 UTC that day, and the flags were in the consensus by 21:00. BadExit tells Tor clients never to use a relay as an exit.

On the morning of October 5,, a scripted restart swept through 55 of Quetzalcoatl's hosts, with the policy still in place. Who ran it is not known. The directory authorities were by then rejecting affected relays from the network, the Tor Project said in its notice, and the two relays Zimmer had stopped were refused when they tried to rejoin, he wrote.

By 17:00 UTC on October 5, no relay with the attacker's policy was in the consensus, and none had returned as of October 9, the directory-data analysis found. Forty-one relays, nine of them Quetzalcoatl's, were still publishing the policy at that point but were not listed.

Tor Metrics' count of relays carrying the Exit flag fell by about 370 between October 3 and October 5, matching the number of affected relays, and had not recovered by October 18.

Ebury, and How the Attackers Got In

Zimmer described his side in a post-mortem on the list on October 7. Two of his servers were running Ebury version 1.8.3: a management server at Contabo that served as the family's VPN gateway and SSH jump host, and a FranTech VPS he calls Switzerland2 that ran two of the exits.

Ebury is a backdoor and credential stealer for OpenSSH that has been active since 2009, according to ESET, which estimated in 2024 that it had infected 400,000 servers, with more than 100,000 still infected in late 2023.

The attacker logged in to the management server on August 28 with the operator account's password on the first try, gained root within five minutes, installed Ebury, then reached Switzerland2 a little over an hour later and installed it there too.

"The root cause was ours: one password reused for SSH login, sudo and the backup passphrase, stored in plaintext on both servers, plus SSH password authentication left enabled on the internet-facing management server," Zimmer wrote. Where the attacker got that password is unknown.

Ebury's backdoor logins leave no record. On October 2, the exits' configuration files were rewritten with no login, sudo command, or cron job in the logs, and the two relays published the attacker's policy at 09:34 UTC. It stayed live for about 52 hours on two relays moving roughly 3.4 TiB a day.

A routine reboot on October 4 killed the attacker's hidden tools, but Ebury came straight back.

The family's "offline" master keys "were not offline: copies sat in the workstation backup on the management server, encrypted with the password the attacker already had," Zimmer wrote. He retired every relay and the bridge in the family and deleted both servers.

This Ebury is a single setuid library file, /usr/lib/x86_64-linux-gnu/libkeyutils.so.1.10.2, with the libkeyutils.so.1 symlink pointed at it. The packaged library is untouched, so dpkg -V and debsums do not catch it, and sshd, sudo, and PAM pass their package checks. Version 1.8.3 is newer than ESET's public indicators, which stop at 1.8.2, and ESET's published detection script, read on October 21, lists no socket name for it.

Marc-Etienne M. Léveillé, who co-wrote ESET's 2014 Ebury paper, wrote its 2024 report and has since left the company, replied that version 1.8.3 has been around since at least June 2026 and posted an updated copy of the script that covers it. "Given how many servers had Ebury between 2009 and 2023 (400 000!), there are most likely other compromised Tor relays out there," he wrote.

How the other 58 operators' hosts were entered is the main open question. Among their relays listed on October 1, 71 of the 101 hosted on FranTech Solutions, the network behind the BuyVM hosting brand, switched to the attacker's policy, against 13 of 9,054 hosted elsewhere, the directory-data analysis found.

Forty relays of 21 operators changed within five and a half minutes on October 1, most by a configuration reload, which the analysis reads as one actor already holding access to all 40.

Léveillé's best guess for the password was a login from a host already running Ebury, with a compromised hosting provider as another possibility. ESET has seen providers whose management servers ran Ebury and whose customers' virtual servers ended up infected, he wrote.

Kaba counted 26 of the 27 compromised servers outside the Quetzalcoatl family at FranTech/BuyVM and asked on the list: "Could they have compromised those servers at the hoster level?"

Quetzalcoatl's own compromise ran through its Contabo management server, and 225 of its 273 affected relays sat on other networks.

Who is behind the campaign is unknown, and so is how many of the affected hosts ran Ebury: Zimmer examined two of his, and the directory data shows only the policy. A fake uppercase CRON daemon and NAT rules redirecting port 22 were among the signs other operators reported to the Tor Project. Zimmer's servers had neither, and whether the cases share one actor is open.

On Zimmer's relays, the port changes meant any mail retrieval could only happen in plaintext, he wrote, and a hidden process named snf ran on Switzerland2 for most of the window. What it did is unknown.

What Relay Operators Should Check

The Tor Project's notice asks Linux relay operators to check Relay Search for an Exit flag or exit policy they did not set, and to look through torrc and any included files for changed ExitRelay, ExitPolicy, ContactInfo, MyFamily or Nickname lines.

It also lists NAT rules on port 22, unknown listening processes or outbound connections, new users, authorized_keys entries, cron jobs and systemd units, and a tor binary that fails its package check. Zimmer's servers showed none of the host-level signs on that list, only the changed exit policy, so a clean host check does not rule out this Ebury.

The signs of the implant, from Zimmer's post, are:

• File: /usr/lib/x86_64-linux-gnu/libkeyutils.so.1.10.2, setuid and owned by no package (63,368 bytes on his servers, with a hash that differs on every server)
• Symlink: libkeyutils.so.1 pointing at that file
• Socket: abstract UNIX socket @event-0YsOG9WSOE
• Process: a fake /sbin/rsyslogd (earlier systemd-udevd or arpd) running inside the ssh.service cgroup
• IP: 185.225.226[.]62, the source of the August 28 login
• SSH key: RSA SHA256:dvACokMYcXJ2om4wuS+TvdtjrAgPK7rC7ZQHDgvBHzk, used to log in to Switzerland2
• SSH keys embedded in the implant: RSA SHA256:KlICz/B59619CpuQdGzgmmvzWBfTMUJ77EwihTYobuo and ED25519 SHA256:OfLY0uF9SwOW9xVjiMXZGDfk6Atmz6CbHy4epknLm8Y
• Interceptor host key: ED25519 SHA256:6baCZCPsl+AfQuujUS81fMEE/C7UeJ+AwjrImqmDB3E, seen on kaba's connection

Check from a rescue system or an offline disk image if you can. On a live server, log in with a key. "Never type a password into a server you suspect, because Ebury will capture it," Zimmer wrote.

Start a shell with H=1 I=1 LD_PRELOAD=":" LD_DEBUG=":" bash to get past the userland rootkit before running Léveillé's updated script or the commands in Zimmer's post.

If you find it, the Tor Project's steps are:

1. take the relay offline
2. preserve the disk and logs before wiping
3. reinstall rather than clean up
4. generate a new relay identity and treat the old keys as stolen
5. rotate every credential that was on the host

Reinstalling matters because the implant survived a reboot on Zimmer's server. Report to bad-relays@lists.torproject.org, and if your IP address was blocked during the incident, write to the same address once your host is clean to have the block lifted, Georg Koppen of the Tor Project said in a follow-up.

from The Hacker News https://ift.tt/olec8dS
via IFTTT

Parasitizing trust: How legitimate infrastructure becomes a delivery pipeline for attackers

• Legitimate infrastructure has become a powerful delivery mechanism for attackers, carrying the inherent trust they once had to build. As Cisco Talos explored in our previous research on weaponizing software-as-a-service (SaaS) notification pipelines, these platforms are increasingly repurposed as proxies for malicious intent.  
• Talos has since tracked a significant acceleration in this trend, observing abuse across more than 25 distinct legitimate platforms in the past year.  
• The abused infrastructure included collaboration, productivity, file-sharing, survey, payment and AI-related platforms.  
• This demonstrates that attackers are not limiting themselves to traditional phishing infrastructure or lookalike domains. Instead, they are systematically subverting the very tools businesses trust.  

Order notification abuse 

Talos recently analyzed two order notification campaigns abusing Staples and Dell transactional email pipelines. Together, these campaigns accounted for roughly 1,400 messages observed by Talos. 

The malicious element was not the outer sender identity, like a simple forged sender or lookalike domain. It was the content of the legitimate order notification workflow rendered. The suspicious content appeared inside the notification itself, in fields that would normally contain shipping information. The attacker’s objective was to use a trusted retail pipeline to create urgency around a high-value purchase and push the recipient toward an attacker-controlled phone number. 

In the first campaign, the message appeared as a Staples order confirmation from "support@orders.staples.com” with the subject line, “Here’s your Staples order #9939818875. Thanks for shopping with us.” The body displayed a plausible purchase for an Apple iPad, including order number, delivery timing, pricing, billing information and standard Staples footer content. The suspicious element was embedded in the order details: “Helpline 806 283 7712,” “Order Confirmed,” and the Staples corporate address appeared in fields normally associated with shipping or billing information. 

Figure 1. Staples order notification

The structure of the message matters. The attacker was not trying to persuade the user to click a crude phishing link. Instead, the message created the impression that an expensive order had already been placed and that the fastest way to resolve it was to call the embedded “helpline.” The desired user action was a phone call. Once the victim moved from email to voice, the attacker could continue the scam through social engineering, payment manipulation, credential theft, or remote assistance fraud. 

The headers reinforced the trust problem. The Staples message showed DKIM alignment for “orders.staples.com” and DMARC passed for the visible Staples domain. The message also passed through forwarding and re-encapsulation paths, including Proton Mail, Microsoft 365, and downstream enterprise mail infrastructure. These hops complicate provenance analysis, but they do not change the core issue: Authentication helped establish that the outer message was credible, while offering no assurance that the phone number or transaction context was legitimate.  

The second campaign used the same pattern in a Dell order received notification. The message was sent from “Dell | Order Received <received@order.dellcom>” with the subject line, “We have your order | Dell Purchase ID: 2009829958247.” The body presented a purchase for Microsoft Project Standard 2024, totaling $736.09. As with the Staples example, the suspicious content appeared in transaction fields. The “Ship To” and “Bill To” sections included “Confirmed Order,” “Helpline 808 232 6397,” and “Call Our Sales Team”. 

The Dell message used the same psychological lever: an unexpected high-value purchase, a legitimate-looking order template, and a phone number positioned as the path to resolution. The attacker did not need the recipient to trust a new domain or unfamiliar brand. The message borrowed credibility from Dell’s order pipeline and redirected the recipient toward attacker-controlled contact information. 

Authentication results showed DKIM passing for Dell-related infrastructure and DMARC passing for “order.dell.com”. As with the Staples sample, forwarding artifacts and SRS-style return paths appeared as the message moved through Microsoft and enterprise mail infrastructure. But the malicious intent did not live in an obviously forged sender. It lived inside the rendered order content. 

Figure 2. Dell order notification

These campaigns illustrate the same trust-boundary failure described in our earlier research on platform-as-a-proxy (PaaP) abuse. In those cases, attackers placed malicious content into SaaS fields that trusted platforms later rendered into notifications. Here, the same concept appears in commerce infrastructure, in the retailer’s order pipeline. The attacker supplies the intent, while the trusted system performs the delivery.  

From a defensive perspective, sender authentication is necessary, but it is not sufficient. SPF, DKIM, and DMARC help answer whether a message came from expected infrastructure. However, they do not answer whether the transaction was legitimate, whether the rendered fields make business sense, or whether the user is being pushed toward an attacker-controlled action. 

Order notifications should be treated as sensitive content. Any field reflected into a transactional message — shipping name, billing name, address line, company name, order note, support field, or fulfillment instruction — can become a delivery vehicle if it is not validated before rendering. Retailers and security teams should correlate order notification content with account history, payment state, shipping context, and known support channels. Transactional templates should reject or flag unexpected phone numbers, URLs, urgency language, and support instructions when they appear in fields where they do not belong. 

In both campaigns, the wrapper was legitimate enough to inherit trust. The payload was attacker-influenced. That distinction is the center of this attack class. 

The abuse of commerce pipelines is merely one manifestation of a broader, systemic vulnerability. Whether the attacker initiates a fake purchase or a fraudulent account sign-up, the root cause remains the same: Platforms are implicitly trusting data that enters their systems from untrusted sources, only to render that data into high-reputation, automated notifications. This same mechanism of reflection — where input is echoed back into an email to a third party — is the engine behind an evolution in list bombing, moving the attack from simple denial-of-service to a sophisticated vehicle for content delivery.  

List bombing: From inbox disruption to content delivery 

List bombing is an abuse technique in which attackers submit a victim’s email address to numerous legitimate registration, subscription or notification workflows, flooding the inbox with automated messages. While this vector is traditionally viewed as a denial-of-service or distraction tactic designed to bury critical alerts in a flood of junk, Talos has observed a subset of cases where this behavior is being repurposed as a delivery vehicle for malicious content. This abuse occurs when an attacker identifies public-facing registration, profile, or project-naming forms that lack sufficient input validation. By inputting a "hostile string" — such as a cryptocurrency-themed lure — into fields intended for a name, company, or title, the attacker forces the platform to treat this data as legitimate user information. When the service reflexively incorporates this input into its automated welcome, verification, or notification templates, the system acts as an unintended carrier, delivering the attacker’s content inside a high-reputation, system-generated email that can pass standard authentication checks. 

The attacker’s objective in these cases is to bypass the security perimeter by laundering their malicious content through the brand reputation of a trusted service provider. While this is not yet a broad industry shift, it represents a calculated abuse of a platform's trust boundary. By embedding their lure in an automated notification, the adversary ensures that the message arrives with the appearance of administrative legitimacy, significantly increasing the likelihood that the recipient will trust the content. The goal is to reach the target's inbox with enough platform authority that the message may be evaluated as routine notification traffic rather than attacker-controlled content. 

Figure 3. Registration field reflection

Beyond the risk to the individual recipient, this vector creates a significant brand liability. When a service provider’s infrastructure is used to broadcast fraudulent content, the resulting user complaints and bounce-backs can degrade the platform's own sender reputation, potentially triggering blocklisting that impacts their legitimate business communications. 

Bounce abuse: When delivery reports carry the lure 

The final vector moves the abuse pattern into the mail system itself. Instead of relying on a retailer, SaaS platform, or registration workflow to generate the message, the attacker attempts to make a delivery status workflow carry attacker-controlled content. 

Bounces, formally known as delivery status notifications (DSNs) or non-delivery reports (NDRs), are generated when a message cannot be delivered. Under normal conditions, a mail system sends the delivery report back to the original SMTP envelope sender. Depending on the implementation, that report may include the original headers, portions of the message body, URLs, attachments, or an encapsulated copy of the failed message. That returned content creates the abuse opportunity.  

In one example Talos observed, a mail delivery system notification carried a WeTransfer-themed file-sharing lure. The administrative wrapper made the message look like routine mail-system noise, while the nested content asked the recipient to engage with what appeared to be a file transfer workflow. The attacker’s goal was to make the phishing lure feel less like an unsolicited external message and more like part of a technical delivery failure that required review. Users are conditioned to view system errors as benign and are far more likely to engage with an "administrative" fix than a suspicious, standalone phishing email.  

Figure 4. Bounce carrying a file-sharing lure

There are several ways this kind of message can reach a victim. In opportunistic backscatter, an attacker sends mail using the victim’s address as the forged envelope sender. If an intermediate system accepts the message and later fails to deliver it, the resulting DSN may be sent back to the forged sender. If the DSN includes enough of the original message, the bounce itself can carry the lure. 

 A second possibility is intentional bounce abuse, where the attacker uses an authenticated, compromised, or otherwise controllable sending context to trigger a delivery failure that returns attacker-influenced content. This differs from an outright forged NDR, where the attacker simply fabricates the bounce message and sends it directly. From the recipient’s mailbox, however, these cases can look similar: A delivery-failure wrapper contains content the attacker wants the user to trust. 

This distinction matters for defenders. A DSN’s administrative appearance does not validate the content inside it. The outer message may be a legitimate delivery report, while the returned or encapsulated content may still contain a phishing link, credential harvesting page, malicious attachment, or social engineering prompt. 

The content-trust gap: A defensive imperative 

Across these vectors, the defensive failure is consistent: Trusted infrastructure is being treated as a shortcut for trusted content. 

Sender authentication remains essential. SPF, DKIM, DMARC, reputation, and infrastructure analysis help determine whether a message came from an expected source. But these controls do not answer a separate and increasingly important question: What was that trusted system instructed to carry? 

Order notifications, registration workflows and delivery reports all create opportunities for attacker-influenced content to appear inside messages that users and security tools are conditioned to trust. In the Staples and Dell campaigns, the suspicious content was a phone number placed into transactional fields. In list bombing and registration abuse, the lure can appear inside reflected account or profile data. In bounce abuse, the malicious content may sit inside returned message data or a nested MIME object. 

Defending against this requires content-aware validation at multiple points in the delivery chain. Platform owners should treat any user-controlled value rendered into an email template as untrusted data. Fields used for names, addresses, company names, project titles, order notes or support instructions should be validated before storage and again before rendering. Phone numbers, URLs, markup, line breaks, and urgent support language should be rejected or flagged when they appear in fields where they do not belong.  

Security gateways should inspect the fully rendered message, not only the sender or template. That includes HTML, text, URLs, redirects, attachments, personalization fields, and nested MIME content. For transactional email, defenders should also evaluate whether the message content aligns with the workflow that produced it. An order notification containing unexpected support numbers, cancellation instructions, or high-urgency language should be treated differently from a routine receipt. 

For delivery reports, recursive MIME inspection is especially important. Gateways should parse DSN containers, extract returned messages or message fragments, and apply normal phishing, malware, and URL analysis to the nested content. A bounce should explain a delivery failure, not provide a blind path for untrusted payloads. 

The broader lesson is that attackers are no longer only exploiting technical vulnerabilities in infrastructure. They are exploiting the assumptions built into business processes. When legitimate systems render attacker-influenced data into trusted notifications, the result can pass authentication checks and still deliver malicious intent.  

Defenders should therefore treat sender trust and content trust as separate but complementary signals. The wrapper can explain where a message came from. It cannot prove that the payload is safe. 

Acknowledgments 

Special thanks to Eric Peterson, Dev Shah, and Adam Katz for their professional guidance and input during the development of this research. 

from Cisco Talos Blog https://ift.tt/uT5s6KC
via IFTTT

JumpServer: Open-Source Bastion Host and Privileged Access Management for Modern Infrastructure

As system administrators and techies, we all know the pain of managing privileged access across dozens, hundreds, or thousands of servers, databases, cloud instances, and network devices. Direct SSH keys scattered everywhere, shared admin passwords, no real auditing, and the constant fear of a breach from a compromised credential. It’s a nightmare that keeps us up at night. We need something that put an order into it.

Enter JumpServer – a popular open-source Privileged Access Management (PAM) platform that acts as a bastion host/jump server with full session recording, fine-grained controls, and multi-protocol support. It’s been battle-tested in production environments for years and offers a transparent, self-hosted alternative to expensive commercial tools like CyberArk.

In this post, I’ll walk you through what JumpServer is, why it matters for sysadmins, how to get it running quickly, key features with real-world usage tips, and some deployment considerations. If you’re responsible for infrastructure security, compliance (think ISO 27001, GDPR, or local equivalents), or just want better control over who accesses what, this should be useful.

Why Consider a Bastion Host / PAM Solution?

Before diving into JumpServer specifics, let’s recall the classic problems:

• Credential sprawl: Admins have root passwords or SSH keys on laptops, shared drives, or password managers (which get breached).
• No visibility: Who logged in as root at 3 AM and ran what commands?
• Compliance headaches: Auditors want proof of least-privilege access, session recordings, and immutable logs.
• Multi-cloud and hybrid mess: Managing access to AWS, Azure, on-prem Linux/Windows, K8s pods, and databases uniformly is tough.

 

 

JumpServer overview

 

 

A proper jump server / PAM centralizes access through a controlled gateway. Users never see direct credentials; everything is proxied, recorded, and auditable. JumpServer does this exceptionally well in an open-source package.

What is JumpServer?

JumpServer is an open-source platform for secure, audited access to assets. It supports SSH, RDP (web or native), databases (MySQL, PostgreSQL, Oracle, etc.), Kubernetes, web apps, and more – all through a clean web interface with HTML5 terminals. No client agents required on target systems in most cases.

Key pillars:

• Authentication: Integrates with LDAP/AD, supports SSO (OIDC, SAML, OAuth), MFA (TOTP, WebAuthn).
• Authorization: Granular RBAC, asset groups, just-in-time (JIT) access via tickets/approvals.
• Account Management: Centralized vault with automated password/key rotation.
• Audit: Full session video recording, keystroke logging, command filtering/blocking, searchable logs.

It’s 100% open source (GPL-3.0) with an active community and optional Enterprise X-Pack for advanced multi-tenancy, extra DB support, etc.

The enterprise option can also be installed via offline package. Community edition has a one-liner for deployment so you’ll need a machine connected to the internet.jumpserver.com

Quick Installation (Get It Running in Minutes)

JumpServer is refreshingly easy to deploy. The recommended quickstart uses a one-liner on a clean Linux server (Ubuntu/Debian or RHEL-based recommended, 4+ cores, 8GB+ RAM).

Basic steps (always check current docs for your version):

1. Prepare a dedicated server/VM. Avoid running it on a domain controller or critical production host.

2. Log in as root (or sudo user) and switch to /opt:

cd /opt

 

3. Run the quick install script:

curl -sSL https://github.com/jumpserver/jumpserver/releases/latest/download/quick_start.sh | bash

 

 

This pulls the latest community edition, sets up Docker Compose (or standalone), and gets everything running. Access it at http://your-ip/ with default admin/ChangeMe credentials (change immediately!).

 

 

The installation of JumpServer

 

For production, consider:

• Offline installation packages for air-gapped environments.
• Kubernetes/Helm for larger scales.
• Separate storage for recordings (object storage like MinIO or S3-compatible).
• Proper firewalling (expose only necessary ports; use reverse proxy like Nginx with TLS).

 

 

The installation takes about 15 min

 

 

Pro tip: Use Docker Compose for easier upgrades and backups. Always follow security best practices – run behind a WAF/reverse proxy, enable MFA from day one, and don’t expose it directly to the internet without strong controls.

After install, the web UI is intuitive: Assets, Users, Permissions, Sessions, etc.

 

 

JumpServer Web User Interface

 

 

Core Features and Sysadmin Tips

Asset Management

Add Linux/Windows servers, network devices, databases, and cloud resources. Auto-discovery is available in enterprise editions. Group assets logically (e.g., “Prod-DBs”, “Dev-K8s”).

Tip: Use system users (the actual credentials stored securely in JumpServer) and separate them from login users. This way, you rotate passwords centrally without touching every admin’s config.

Connecting to Assets

• SSH: Web terminal (great for quick access from anywhere) or native client.
• RDP: Browser-based or native with signing options for security.
• Databases: Web SQL client-like access.
• K8s: Direct pod access.

Everything is recorded. You can replay sessions like a video, search commands across all sessions.

Real-world usefulness: Contractors or junior admins get temporary access without giving them full SSH keys. Command filtering can block dangerous commands like rm -rf / or shutdown.

Permissions and RBAC

Define roles, asset permissions, and approval workflows. JIT access via tickets is excellent – user requests access, approver (you or manager) grants time-boxed permission.

Tip for techies: Combine with LDAP sync for automatic user provisioning. Implement least privilege strictly – most users should only have access to specific assets for specific times.

Auditing and Compliance

This is where JumpServer shines. Every login, command, and session is logged. Real-time alerts for suspicious activity (configurable). Export reports for audits.

Pro tip: Store recordings on immutable storage. Integrate with SIEM if needed for advanced correlation.

Deployment Models and Scaling

• All-in-one: Fine for small teams/labs.
• Distributed: Separate components (core, web, celery tasks, recording storage) for high availability and performance.
• Multi-tenant: Enterprise feature for MSPs or large orgs with isolated departments.

For large environments, plan for Redis, MySQL/PostgreSQL backend, and sufficient CPU/RAM for concurrent sessions. Monitor with Prometheus or your existing tools.

High availability notes: Use load balancers, clustered databases, and replicated storage. Test failover thoroughly.

Comparison to Commercial Tools

Many teams migrate from legacy PAM solutions to JumpServer for cost savings (no per-user licensing), transparency, and flexibility. You get core PAM capabilities without vendor lock-in. Enterprise support is available if you need SLAs.

You can watch an quick install video which shows you quickly the 5 necessary steps to understand this cool environment.

It’s not perfect – documentation can be stronger in some areas for non-Chinese speakers, and some advanced features require the paid edition – but the community version covers 80-90% of needs for most organizations.

Potential Gotchas and Best Practices

• Security first: Treat JumpServer itself as a critical asset. Harden the host, regular updates, backups of config and DB.
• Performance: Session recording can consume disk I/O. Plan storage accordingly.
• Backup strategy: Regular DB dumps + asset configs + recordings.
• Testing: Start with a pilot for a non-prod environment. Train your team on the workflows.
• Integrations: API is powerful for automation (Python, Go examples available). Great for custom ticketing or CI/CD pipelines.

From a sysadmin perspective, the biggest win is regaining control and visibility without massive overhead.

Final Words

Is JumpServer Right for You? If you’re a sysadmin or DevOps engineer tired of ad-hoc access methods and looking for a robust, auditable solution that scales from a few servers to enterprise hybrid clouds, JumpServer is worth serious evaluation. It’s practical, feature-rich, and community-driven. I like it!

Deploy it in your lab today – the quickstart really does take under 30 minutes. Play with asset addition, permissions, and session replay. You’ll quickly see how it can tighten your security posture while making daily operations smoother. For the latest installation guides, features, and release notes, head to the official site: https://www.jumpserver.com/ and documentation.

FAQ

What is JumpServer?

JumpServer is an open-source Privileged Access Management (PAM) platform that acts as a bastion host for secure and audited access to infrastructure. It centralizes privileged access and records user activity instead of relying on scattered SSH keys or shared administrator credentials.

What systems and protocols does JumpServer support?

JumpServer supports SSH, RDP, databases such as MySQL, PostgreSQL, and Oracle, Kubernetes, web applications, network devices, and other infrastructure assets. Users can access many resources through its web interface and HTML5 terminals.

Does JumpServer require agents on target servers?

In most cases, no client agent is required on target systems. Connections are managed through the JumpServer gateway, which proxies and audits access to infrastructure resources.

What authentication and access controls does JumpServer provide?

JumpServer can integrate with LDAP and Active Directory and supports SSO through OIDC, SAML, and OAuth. MFA options include TOTP and WebAuthn. Access can be controlled through granular RBAC, asset groups, approvals, and just-in-time access workflows.

Can JumpServer record administrator sessions?

Yes. JumpServer can record complete sessions, log commands and keystrokes, filter or block commands, and provide searchable audit logs. Recorded sessions can later be replayed for investigation or compliance reviews.

Does JumpServer support just-in-time privileged access?

Yes. Administrators can configure ticket-based approval workflows that grant users access to selected assets for a limited period. This can be used for contractors, junior administrators, or other users who should not receive permanent privileged credentials.

How is JumpServer installed?

The Community Edition provides a quick installation method for Linux servers. The article describes deployment on a dedicated Ubuntu, Debian, or RHEL-based server and notes that Docker Compose can be used for easier upgrades and backups.

Can JumpServer be used in large environments?

Yes. Small environments can use an all-in-one deployment. Larger installations can separate core services, web components, task processing, databases, and recording storage. High-availability deployments can use load balancers, clustered databases, and replicated storage.

What should be planned before deploying JumpServer in production?

The article recommends treating JumpServer itself as a critical security asset, keeping it updated, protecting it behind appropriate network controls, enabling MFA, planning storage capacity for session recordings, backing up databases and configuration, and testing the platform first in a non-production environment.

from StarWind Blog https://ift.tt/BpaMfq4
via IFTTT