#webshell

Read Time:3 Minute, 15 Second

A newly documented attack chain named WP2Shell combines two WordPress Core vulnerabilities to move from an unauthenticated web request to administrator access and server-side code execution. The technique can create a privileged account, upload a plugin containing a web shell and leave attackers with a durable command interface on the underlying host.

Seqrite researchers published their analysis on October 16, detailing how CVE-2026-63030 and CVE-2026-60137 reinforce each other. Their work demonstrates a serious path against unpatched sites, although it does not establish widespread exploitation in the wild.

Two flaws create one dangerous pathCVE-2026-63030 affects the WordPress REST API batch controller at /wp-json/batch/v1, which is designed to process several API operations in one submission. According to the research, specially nested requests can confuse route handling and reach behavior that should require authentication. This issue provides access to the next vulnerable code path but does not directly execute commands on its own.

CVE-2026-60137 is an SQL injection weakness in the posts endpoint. The public author_exclude parameter maps to author__not_in in WP_Query, where insufficient input handling can alter a database query. Chained through the route flaw, an external attacker can reach this condition without first signing in.

The combined proof of concept turns database access into an administrator-level foothold and then code execution. The distinction matters for defensive analysis: neither vulnerability should be simplified as a standalone web shell. The takeover is possible because the authentication bypass path exposes the injection weakness and the resulting privileges enable plugin installation.

What the attack leaves behindSeqrite’s demonstrated sequence creates an unexpected administrator, stages a ZIP file beneath the uploads directory, extracts PHP content through the upgrade area and moves a generated plugin into wp-content/plugins. The plugin then acts as a web shell that can execute operating-system commands.

Useful indicators include temporary files matching temp-write-test-*, archives such as wp2shell_4e9b3641.zip, directories named wp2shell_, and similarly named PHP files. Defenders should also review traffic to the batch endpoint and look for new administrators whose creation time does not match a legitimate change.

Web-server processes may legitimately write files during plugin installation, so a process such as httpd.exe touching WordPress directories is not proof by itself. Stronger evidence comes from the distinctive naming patterns, an unusual request sequence, unauthorized accounts and PHP files that do not match an approved plugin release.

Affected releases and defensive stepsThe report lists WordPress 6.9.0 through 6.9.4 and 7.0.0 through 7.0.1 as vulnerable to the complete chain. Versions 6.8.0 through 6.8.5 are affected by the SQL injection component. WordPress 6.8.6, 6.9.5 and 7.0.2 are identified as fixed versions; later supported releases should also contain the corrections.

Upgrade to the appropriate fixed branch or a later supported WordPress release and confirm the update completed.

Search access logs for suspicious nested requests to /wp-json/batch/v1.

Review administrator accounts and investigate any unexplained additions.

Compare plugin, cache, uploads and upgrade directories with known-good baselines.

Hunt for WP2Shell filename patterns and newly written PHP files.

Restricting unauthenticated access to sensitive REST functionality may reduce exposure in some environments, but it is not a replacement for patching. Internet-facing sites behind managed hosting or an edge security service should still verify the actual WordPress Core version rather than assuming the provider applied the update.

If indicators are present, preserve logs and filesystem evidence before removing artifacts. Disable malicious plugins, rotate WordPress and infrastructure credentials, and investigate for persistence outside the web root. A site that now reports a patched version may still contain accounts or code installed before the upgrade, so remediation must address both the original vulnerabilities and the consequences of earlier access.

Si parla di:

Toggle

Per sei mesi, tra ottobre 2025 e aprile 2026, un gruppo di aggressori ancora privo di attribuzione ha violato server #Linux appartenenti a enti #governativi e a infrastrutture ad essi collegate. Dietro di sé ha lasciato un indizio insolito per questo tipo di operazioni: commenti nel codice sorgente che sembrano usciti direttamente dalla risposta di un chatbot, passo dopo passo, come se l’operatore avesse semplicemente copiato l’output di un modello linguistico dentro lo script e lo avesse lanciato. Unit 42 di Palo Alto Networks ha ricostruito l’intera campagna, tracciata come cluster CL-UNK-1211, svelando un arsenale che mescola un #RAT multipiattaforma scritto in Go, web shell camuffate da componenti Plesk e tecniche di furto credenziali al confine tra ingegneria sociale e sabotaggio della shell.

Un cluster senza nome, ma con moltissime impronteUnit 42 non ha attribuito CL-UNK-1211 a un gruppo nazionale o a una crew cybercriminale nota: non ci sono sovrapposizioni di infrastruttura, #malware o modus operandi sufficienti a collegare la campagna ad attori già catalogati. Quello che i ricercatori Roey Porat e Tom Fakterman hanno potuto ricostruire, grazie alla #telemetria raccolta su più ambienti compromessi, è però un quadro operativo molto dettagliato: l’obiettivo dichiarato era la raccolta di #intelligence contro entità governative e organizzazioni affiliate a Stati, con un focus quasi ossessivo su server Linux e #database interni.

L’accesso iniziale passava quasi sempre da una web shell #PHP caricata su sistemi già esposti o compromessi in precedenza. Da lì, gli aggressori modificavano la direttiva auto_prepend_file nella configurazione PHP globale (in /etc/php/ e /opt/plesk/php/), così da far eseguire il proprio codice malevolo a ogni singola richiesta gestita dal server, indipendentemente dall’applicazione web effettivamente in esecuzione. La web shell principale, salvata come /usr/lib/php/plesk_sys_driver.php, si mimetizzava deliberatamente tra i file legittimi del pannello di hosting Plesk.

SysGoRAT: la backdoor che parla WebSocketIl componente più sofisticato della campagna è un trojan di accesso remoto inedito, che Unit 42 ha battezzato SysGoRAT: scritto in Go, compila per Linux e Windows e comunica con l’infrastruttura di comando e controllo tramite WebSocket cifrato (wss:///ws). Sul disco si nasconde sotto nomi plausibili come sys-control-client, pip2.7 o ea_install, e per la persistenza crea un servizio systemd dedicato, un cron job o, su Windows, una voce di avvio mascherata da componente OneDrive.

Il protocollo supporta sette tipologie di comando — tra cui esecuzione shell interattiva, trasferimento file, screenshot e, particolarmente interessante, l’uso della macchina infetta come proxy SOCKS interno per raggiungere segmenti di rete altrimenti irraggiungibili dall’esterno. È lo stesso schema che gli aggressori hanno riutilizzato più volte per muoversi lateralmente una volta dentro il perimetro.

Il furto di password passa da un finto prompt di sudoUna delle tecniche più curiose documentate nel report riguarda il furto delle credenziali di amministrazione. Gli aggressori modificavano il file .bashrc dell’utente in modo che, al momento di digitare sudo, comparisse una richiesta di password identica in tutto e per tutto a quella originale: l’input veniva silenziosamente salvato in un file camuffato da log legittimo (Solarwinds.StatusLog.txt — un nome scelto apposta per confondersi con l’infrastruttura di monitoraggio, non perché SolarWinds risulti realmente compromessa), dopodiché il vero comando sudo veniva eseguito normalmente, senza che la vittima notasse nulla. Un trucco identico, con la stessa logica di intercettazione silenziosa, era stato inserito anche nella pagina di login dei pannelli di amministrazione web compromessi.

Per l’escalation dei privilegi locali, il toolkit include LinPEAS per l’enumerazione automatica delle debolezze di sistema e un exploit per PwnKit (CVE-2021-4034), oltre a binari SUID rinominati come .libpython-helper e .libsystemd-helper — rispettivamente un interprete Python con os.setuid(0) forzato e una shell SUID root custom — e persino una copia di /bin/bash con bit SUID impostato, salvata come .tourch.

L’indizio dell’intelligenza artificialeCiò che distingue CL-UNK-1211 da una campagna di spionaggio Linux “qualunque” è lo stile del codice. Gli script PHP, Bash, Python e JavaScript usati nelle varie fasi dell’attacco contengono commenti insolitamente estesi e discorsivi, con spiegazioni passo-passo del tipo che un modello linguistico produce quando gli si chiede di scrivere ed esplicitare uno script, intestazioni di sezione pensate più per essere lette da un sistema automatico che da un umano, e un uso pervasivo della codifica Base64 per offuscare comandi altrimenti banali. Gli operatori passano con disinvoltura tra quattro linguaggi diversi nella stessa catena d’attacco, un comportamento compatibile sia con la copia diretta di output generato da IA, sia con l’uso di un agente automatizzato per produrre ed eseguire il codice.

Unit 42 è cauta nel trarre conclusioni definitive — non ci sono prove di un’esecuzione realmente autonoma, “agentica”, dell’intera catena — ma un dettaglio rafforza l’ipotesi: lo script pensato per comprimere intere caselle di posta elettronica in archivi ZIP contiene un errore di sintassi che ne impedisce l’esecuzione, un tipo di errore plausibile quando il codice viene generato o adattato rapidamente senza una verifica accurata, e poi lanciato così com’è.

Alla ricerca degli account social dei dipendenti governativiTra gli strumenti più particolari del kit figura uno script, search_social.php, progettato per analizzare le intestazioni delle caselle di posta elettronica di servizio alla ricerca di riferimenti a Facebook, Instagram, TikTok e altre piattaforme social, nel tentativo di collegare indirizzi email istituzionali ad account personali dei dipendenti. Una volta ottenuto l’accesso root — in diversi casi documentato nel report — gli aggressori lasciavano proprie chiavi SSH in authorized_keys per garantirsi un rientro futuro, e si muovevano verso server SQL con un doppio salto tramite sshpass e, dove disponibile, xp_cmdshell su MSSQL.

Cancellare le tracce, quasi come un pentest legittimoNella fase finale, gli attaccanti cancellavano log e alteravano i timestamp dei file con tecniche di timestomping (MITRE ATT&CK T1070.006), lasciando indizi — come le password di comodo RedTeamOps2025 e pentest123 trovate nell’ambiente — che ricordano da vicino l’attività di un red team legittimo. In almeno un caso lo script ha tentato di terminare i processi di Cortex XDR installato sull’host, ma la protezione ha bloccato l’azione, permettendo a Unit 42 di osservare e documentare la catena prima che venisse ripulita.

Due righe per i difensoriApplicare regole restrittive sul traffico in uscita per limitare reverse shell e connessioni verso servizi di file-sharing anonimi (transfer.sh, bashupload.com, filebin.net, l’API di catbox.moe).

Monitorare con EDR l’uso anomalo di netcat, bash e python per aprire shell interattive o named pipe.

Verificare periodicamente la direttiva auto_prepend_file nelle configurazioni PHP e cercare file PHP estranei nelle directory di sistema, non solo in quelle delle applicazioni web.

Controllare .bashrc, authorized_keys e le unità systemd/cron per persistenza non autorizzata, inclusi nomi plausibili ma non riconosciuti (es. varianti di “sys-“, “libsystemd-“, “libpython-“).

Non fidarsi del solo stato dei log: la cancellazione delle tracce è parte integrante del TTP di questo cluster.

Dare priorità alla patch di CVE-2021-4034 (PwnKit) sui sistemi Linux non ancora aggiornati.

Il caso CL-UNK-1211 si inserisce in una tendenza che Unit 42 e altri vendor stanno osservando sempre più spesso nel 2026: l’IA generativa non sta (ancora) creando exploit del tutto nuovi, ma sta riducendo drasticamente il tempo necessario a un operatore umano per scrivere, adattare e distribuire strumenti di post-exploitation efficaci su più piattaforme. Per i difensori, questo significa prepararsi a campagne più rapide da assemblare, più eterogenee nel linguaggio di sviluppo usato e, paradossalmente, più facili da individuare proprio per lo stile di commento innaturale che il codice generato da LLM porta spesso con sé.

Indicatori di compromissioneIP C2 / infrastruttura:
45.88.188[.]140 198.23.185[.]234 138.68.244[.]146
185.21.136[.]6 72.61.89[.]179 104.194.158[.]65 (default SysGoRAT C2)
109.224.53[.]140 162.243.175[.]162 154.93.37[.]228
141.164.58[.]87 88.80.150[.]232 88.119.167[.]57
173.212.247[.]23 104.248.131[.]53 147.182.224[.]216
93.93.112[.]57 192.210.183[.]17
Domini:
magento[.]ink
solidmonpe[.]com
wibu-bau-bawang[.]online
beraskencur[.]site
Percorsi/artefatti su host compromessi:
/usr/lib/php/plesk_sys_driver.php (web shell camuffata da componente Plesk)
.libpython-helper, .libsystemd-helper (SUID helper per privilege escalation)
.tourch (copia SUID di /bin/bash)
Solarwinds.StatusLog.txt (log del credential-logger su .bashrc)
/dev/shm/.gs-10085/ (GSocket mascherato da kcached / gs-dbus)
sys-control-client, pip2.7, ea_install (nomi su disco di SysGoRAT)
C2 SysGoRAT (WebSocket):
wss:///ws
MITRE ATT&CK:
T1070.006 - Indicator Removal: Timestomping
T1068 - Exploitation for Privilege Escalation (PwnKit / CVE-2021-4034)
T1505.003 - Web Shell
T1556 - Modify Authentication Process (hijack sudo via .bashrc)
Fonte primaria: Unit 42, Palo Alto Networks -
unit42.paloaltonetworks.com/ai-campaign-targets-linux-infrastructure/

Read Time:3 Minute, 30 Second

A single operator appears to have used coordinated AI agents to compromise more than 100 company websites at an estimated token cost of about $5,000. The campaign, documented through exposed management dashboards and reported in a Reuters investigation, illustrates how agentic systems can turn one person’s objectives into long-running, multi-step intrusion attempts.

The activity began on September 25 and touched more than 1,200 websites, primarily online stores in the United States, Canada, Australia and Japan. Targets included sites associated with Deere, SharkNinja and Cummins, although the effects differed and the amount of stolen data, if any, could not be determined.

Cairn coordinated the attack workflowNorForge researcher Snorre Fagerland discovered the operation while looking for exposed installations of Cairn, an open-source platform designed to coordinate AI agents. Around October 2, he found roughly two dozen installations apparently supporting malicious work. Cairn is a general problem-solving engine, not a purpose-built hacking utility, but its ability to share findings and manage tasks made it useful for offensive automation.

Operators supplied a target and a desired outcome. Agents then searched for weaknesses, recorded discoveries on a common project board and selected new approaches when initial attempts failed. A preparatory pipeline used Microsoft’s Playwright browser automation to confirm that shopping sites could accept orders before sending them into the agent workflow.

Instructions emphasized routes to code execution without authentication: SQL injection, unsafe file uploads, login bypasses and insecure handling of stored objects. The apparent objective was durable access to commerce and payment environments that could later be monetized.

Evidence of adaptive exploitationNorForge labeled the largest Chinese-language cluster AIA0001 and linked it to 14 dashboards containing more than 1,100 attack projects. Chinese instructions do not prove the operator’s nationality, and researchers saw no clear evidence of state sponsorship.

One claimed compromise was independently checked by visiting an address recorded by the agent. The hardware vendor’s site hosted a live uploader webshell capable of placing additional files on the server. According to the agent’s notes, the intrusion chained unauthorized writes to a memcached session store, unsafe PHP object deserialization and legacy Zend Framework components.

In another project, the agents failed against the main application, searched related infrastructure, discovered an exposed control panel and spent hours probing its data handling. They eventually reported command execution. This ability to preserve context and pivot distinguishes the workflow from a fixed vulnerability scanner that simply runs a predetermined checklist.

Low marginal cost changes the economicsSuccessful AIA0001 tasks ran for just under 23 hours on average, and one continued for more than five days. NorForge estimated an overall success rate near 10 percent, although targets and goals varied. Fagerland put the main campaign’s token bill near $5,000—approximately $50 for each successful intrusion. A separate estimate placed the average task near $5 once failures and early terminations were counted. These are research estimates, not verified provider invoices.

Worker labels suggested a Claude Code arrangement paired with a DeepSeek model, but the complete configuration was not confirmed. The important defensive signal is not a particular model brand. It is the combination of persistent automation, shared memory, browser control and cheap parallel experimentation.

Reported impact and defensive prioritiesDeere said it took corrective action and found no evidence that sensitive information was accessed. SharkNinja described the affected asset as a separate product-support site and said the threat was contained. Cummins was investigating a possible incident involving a third-party-operated website.

The exposed dashboards also revealed hundreds of secrets and information belonging to legitimate penetration-testing customers, showing that poorly secured agent infrastructure can endanger both attackers and authorized teams. Organizations deploying such tools should protect consoles with strong authentication, restrict network access and avoid storing reusable credentials in project data.

Defenders should patch public applications, remove exposed administration panels, monitor for unexpected files in web roots and investigate suspicious requests across related subdomains. When a webshell is found, isolating the host and removing the file is only the beginning: responders must determine what credentials, data and neighboring systems were reached. AI has not eliminated familiar web flaws, but it has made patient exploitation and repeated pivots dramatically cheaper.

Read Time:3 Minute, 23 Second

Two major South Korean churches have suffered extensive intrusions that exposed records associated with more than one million congregants, along with donation, payroll, employee and administrative information. The attacks followed different entry paths but converged on a common weakness: loosely controlled connections between public-facing applications, databases, internal services and cloud storage.

OASIS researchers reconstructed the activity from tools, stolen files and operator reports recovered from an attacker-controlled server. Their findings point to multi-stage intrusions involving application compromise, credential recovery, lateral movement and off-site staging rather than a single malware family. Because datasets can overlap, the precise number of unique people affected has not been independently confirmed.

A web shell opened the first environmentAt the first church, attackers gained a foothold through a web shell placed in an enterprise resource planning system. They reverse engineered ERP application components, decrypted database settings and obtained administrator access to Microsoft SQL Server. The attackers then used the database server’s xp_cmdshell capability to execute operating-system commands and move into linked systems.

From there, access expanded into membership, accounting, physical-access, library, chat and mail databases. The operators bypassed a database-monitoring control, recovered a MariaDB root password and found hardcoded network-attached storage credentials in backup-related configuration. The chain shows how one exposed application can become a bridge to several otherwise separate repositories.

The recovered collection contained approximately 960,000 congregant records updated during the previous two years, including names and South Korean resident registration numbers. It also included about 330,000 donation entries, 68,000 document-creation records, more than 14,000 chat messages and 6,874 login accounts. Investigators identified 47.3 GB across 13,939 files in a compromised MinIO bucket used for staging.

Leaked credentials and IDOR drove the second attackThe second church was reached through previously leaked credentials and authorization weaknesses in groupware and membership services. Insecure direct object reference flaws occur when an application accepts a record identifier supplied by a user but does not confirm that the user is permitted to view or change that record.

Using a valid member session, the attackers could access other users’ plaintext PINs and reset an account with manager-level privileges. They obtained roughly 89,000 congregant records, 383 employee records, 286 human-resources entries, 96 employee photographs and internal approval documents. Researchers also found exposed college-ministry APIs and cloud storage that allowed unrestricted reading and writing.

These details underline why valid credentials cannot substitute for authorization. Every request for a record must be checked against the current user’s privileges, even after authentication succeeds. Password-reset functions require especially strong safeguards because they can turn limited access into account takeover.

Connected systems multiplied the damageIn the first environment, the attack progressed from an internet-facing ERP component to database administration, operating-system execution, backup storage and cloud staging. In the second, a combination of exposed credentials and missing object-level checks crossed groupware, membership, SAP and storage services. Hardcoded secrets and excessive service privileges allowed the operators to keep moving after the initial compromise.

Religious and community organizations can hold a uniquely sensitive mix of identity, family, donation and communication data. Criminals could use that material for identity fraud, tailored phishing, extortion or scams that exploit trust within a congregation.

Containment and prevention stepsRemove unauthorized web shells and preserve forensic copies before rebuilding affected application servers.

Rotate database, NAS, cloud and application credentials; revoke tokens and invalidate active sessions.

Disable xp_cmdshell where it is not operationally necessary and constrain linked-server privileges.

Review ERP, SQL Server, NAS and cloud logs for unusual exports, bulk downloads and unexpected external connections.

Test every sensitive API for object-level authorization and strengthen privileged password-reset workflows.

Eliminate secrets from source code, configuration backups and publicly reachable storage.

Organizations should also alert affected people with clear guidance about targeted fraud and credential reuse. The broader lesson is architectural: segmentation, least privilege and enforced authorization can stop an initial application breach from becoming an organization-wide data loss event.