AT&T’s Unix PC — We Hardly Knew You


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

Before Linux, there was Unix. It was great, but it was and has been plagued by problems with licensing and proprietary competition. [Vintage Appartus] recalls, for example, the AT&T Unix PC from the 1980s. It was awesome, but you’ve probably never heard of it. For 1985, it was a nice setup. You got a 10 MHz Motorola 68010, 512K of RAM (but upgradable to 4M), a floppy, a modem, a 720×384 monochrome screen, and a 10 or 20 MB hard drive. You can check out the video explaining the machine and its problems below.

Physically, the computer looked like a high-end Apple ][ with a removable keyboard and a built-in monitor. Expansion was via three slots. Cold start took about three minutes, and then you have a fairly normal Unix setup for the period.

The sample machine uses a disk emulator, so the video shows the computer running much faster than it would with a real period hard drive. The card also has an 8086 expansion board that can boot MSDOS, an important feature in 1985.

We’d like to see inside the box. Why did it fail? The video says it was very slow and since Unix does more than DOS, it was perceived as very slow compared to an IBM PC. This was made worse by a very slow hard drive that was prone to failure. The price didn’t help. Apparently, the list price at introduction was $15,000. A comparable IBM AT was around half of that. To make the machine really usable, you’d have to throw even more money at it.

While 1985-era Unix isn’t as nice as what we have today, if you spent time on older versions, you’d appreciate what it does do. Unix workstations did have their day, and they were great. But your desktop will probably run circles around even the best of them today.

youtube.com/embed/_x3uxKfFI-0?…


hackaday.com/2026/04/30/atts-u…

Electronics Near Zero


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

Normally, when you design an electronic gadget, you worry about how hot it will get. Automotive-grade components, for example, often have higher allowable temperatures than commercial parts. However, extremely cold environments, such as deep space or the interiors of quantum computers, are also challenging. Researchers at King Abdullah University of Science and Technology believe gallium oxide may be key to operating near absolute zero.

According to [Vishal Khandelwal], one of the researchers, most conventional electronics fail below -173C or 100K. Quantum computers routinely operate at 4K. However, β-Ga2O3 is a wide-bandgap semiconductor that has low current leakage and works at high temperatures up to 500C. However, it also avoids the freeze-out effect that traps electrons in other semiconductor materials.

The team built two devices from the material seeded with a silicon dopant. The first was a FET with a fin-shaped geometry. The second was an inverter. Both operated reliably down to 2K.

Gallium oxide has many interesting properties. For that matter, so does gallium.


hackaday.com/2026/04/30/electr…

USB-C Charger Juices Up 100 Devices At Once


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

Back when phones used to ship with chargers in the box, you’d get a plugpack that could charge one device. Aftermarket manufacturers eventually started making chargers with four or five ports which were great for travelling. But what if you wanted to charge even more devices? You might build something like this rig from [DENKI OTAKU].

The goal was to build a charger that could handle 100 devices at once. The charger is designed to charge devices at up to 1.5 amps. That’s no mean feat, as the device would have to be able to deliver 150 amps total when fully loaded. As for the actual design, though, it’s relatively simple. [DENKI OTAKU] simply built a simple USB-C charger PCB based around an off-the-shelf chip which has ten individual chargers on it, and stacked it up ten of those in a housing made out of aluminium extrusion. To deliver the current to run all these chargers, the rig got two massive switching power supplies to feed the charger array a massive amount of current. The open enclosure design here makes sense, in that it probably helps keep everything cool.

The only thing missing from the build video? A heavy-duty test. We’d love to see if it actually holds up under full load with 100 phones connected. We have some suspicions as to whether the traces on the PCBs would hold up under a continuous 15 amp load, for example. Still, if you wanted to provide phone charging en-masse at an event or similar, this kind of simple stacked design could be an easy way to go.

Phone chargers are still moving forward; the last big leap was the adoption of GaN technology. Video after the break.

youtube.com/embed/qnqJ6ANNSoM?…


hackaday.com/2026/04/30/usb-c-…

Five Different Styles of Cardboard Hinges


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


Simple paper hinge. (Credit: Itoshige Studio, YouTube)Simple paper hinge. (Credit: Itoshige Studio, YouTube)
One doesn’t generally associate cardboard with structural components like hinges, but [Itoshige Studio] assures us that you can absolutely create hinges out of this ubiquitous material. In total the video covers five different designs, ranging from the simple and straightforward to an interlocking tab design that approximates a typical steel hinge with paper rod to keep both sides of the hinge together.

The most simple hinge is unsurprisingly just a strip of craft paper, which is also demonstrated as the hinge for a wooden box in lieu of the typical metal hinge. This same principle is then demonstrated for a fancy cardboard box.

From here the hinge designs increasingly get more involved, with first a seamless hinge variation, and then a kamichoban hinge design that’s inspired by traditional Japanese room dividers and furniture, using panels that are interconnected with overlapping sections to create a fascinatingly flexible hinge that can fully fold either way.

The flush hinge design is somewhat like the craft paper hinge, but significantly fancier and probably sturdier, while also looking pretty good on something like a cabinet. Finally the interlocking tab hinge is effectively a cardboard version of the hinge design that’s found on every room’s door, with a similar level of flexibility. This is obviously the trickiest one to assemble and get right, but it has its own charm.

Considering that all of these examples use regular corrugated cardboard that we get shipped to our homes by the truckload, the cost to try these examples is your time plus some basic tools and glue. The author also sells a book that contains templates – in addition to digital versions – for these hinges and other designs, if you’d like to enjoy the 100% paper experience.

Thanks to [greg_bear] for the tip.

youtube.com/embed/TOm8APHrVas?…


hackaday.com/2026/04/30/five-d…

Making the Osmo Pocket 4 a More Serious Camera


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

The Osmo Pocket 4 is a handheld gimballed camera that’s perfect for shooting running content on the go. However, it’s got a weird sort of form factor and is limited when it comes to things like fitting filters or recording quality sound. To that end, [Byron Seven] whipped up an upgrade kit that turns the Pocket 4 into more of a “real” camera.

The idea is simple enough—the Osmo Pocket 4 is packaged in a 3D printed shell that expands its capabilities. It’s tucked into the structure with a USB power bank that greatly increases how long you can shoot before the batteries run out. In front of the gimbal head, there’s a fitting that allows attaching standard camera filters for visual effect. Topside there’s a handle for better physical control of the camera, along with a rail mount for a DJI wireless mic and a phone to act as a monitor. Down below, there’s a quick-connect fitting so the camera can be slammed on and off a tripod with ease. What’s great is that you can slot a Pocket 4 into this rig when you need, and pull it back out and use it as normal when you’re done.

If you’ve enjoyed the Osmo Pocket 4 but wished you could throw a polarizer on it or chuck it around more, this is a great build to explore. We’ve seen some fun stuff done with non-traditional cameras before, too.

youtube.com/embed/9JMBuVGPznA?…


hackaday.com/2026/04/30/making…

Cybersecurity & cyberwarfare ha ricondiviso questo.

#Copy #Fail: New #Linux bug enables #Root via page‑cache corruption
securityaffairs.com/191519/hac…
#securityaffairs #hacking
Cybersecurity & cyberwarfare ha ricondiviso questo.

Il potenziale inespresso della maglieria digitale come contro-concetto alla moda veloce

La maglieria digitale in quanto approccio produttivo, collega la progettazione computazionale a processi sia materiali che immateriali.
Una serie di conversazioni con designer, ingegneri e professionisti che stanno attivamente plasmando questo settore.

zoeromano.eu/2026/04/26/the-un…

@eticadigitale

cc @valhalla

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.

LAPSUS$ colpisce Checkmarx: 95 GB di codice sorgente su dark web e la supply chain dei tool di sicurezza nel mirino
#CyberSecurity
insicurezzadigitale.com/__tras…


LAPSUS$ colpisce Checkmarx: 95 GB di codice sorgente su dark web e la supply chain dei tool di sicurezza nel mirino


Quando a essere violato è uno dei principali vendor di sicurezza applicativa — uno strumento usato per rilevare vulnerabilità nel codice altrui — le implicazioni si estendono ben oltre l’azienda stessa. Il gruppo LAPSUS$ ha pubblicato sul dark web 95 gigabyte di dati riservati di Checkmarx, inclusi codice sorgente, chiavi API e credenziali di database. È l’ultimo capitolo di una campagna supply chain orchestrata da un attore noto come TeamPCP, che da settimane sta sistematicamente compromettendo l’ecosistema degli strumenti di sviluppo e sicurezza.

Cosa è stato esfiltrato


Il 25 aprile 2026, LAPSUS$ ha rivendicato pubblicamente l’attacco a Checkmarx, pubblicando un archivio di circa 95 GB che include codice sorgente dei repository GitHub privati dell’azienda (tra cui componenti di KICS, il motore open source per la scansione di configurazioni cloud e IaC), un database dei dipendenti con informazioni personali e credenziali interne, chiavi API per servizi di terze parti e integrazioni, e credenziali di database MongoDB e MySQL dell’ambiente di sviluppo.

Checkmarx ha confermato l’autenticità del dump in un advisory pubblicato il 26 aprile, precisando che i repository GitHub compromessi sono separati dall’ambiente di produzione per i clienti e che nessun dato cliente è stato esposto direttamente. Tuttavia, la presenza di chiavi API e credenziali nei file esfiltrati amplia significativamente la superficie di attacco potenziale.

Il vettore: la campagna supply chain TeamPCP


L’accesso ai sistemi di Checkmarx non è stato ottenuto tramite un attacco diretto, ma attraverso la compromissione della supply chain di sviluppo software. La data del breach originale è il 23 marzo 2026, quando TeamPCP ha iniettato codice malevolo in componenti dell’ecosistema Checkmarx disponibili pubblicamente. Le immagini Docker KICS ufficiali su Docker Hub sono state sostituite con versioni trojanizzate contenenti uno stealer di credenziali: gli sviluppatori che le utilizzavano nelle pipeline CI/CD scaricavano automaticamente il malware. Parallelamente, due estensioni VS Code correlate a Checkmarx pubblicate su marketplace sono state compromesse con funzionalità di esfiltrazione che operavano silenziosamente in background.

Il nome TeamPCP emerge anche in connessione con le 73 estensioni malicious su Open VSX scoperte a fine aprile, suggerendo una campagna coordinata e ad ampio raggio contro l’intero ecosistema degli strumenti DevSecOps. Il modello è chiaro: compromettere prima gli strumenti che gli sviluppatori di sicurezza usano quotidianamente, per poi risalire — tramite le credenziali rubate — ai sistemi più preziosi.

Chi è LAPSUS$


LAPSUS$ è un gruppo di cybercrime con una storia operativa peculiare: composto prevalentemente da giovani hacker (diversi dei quali minorenni all’epoca degli attacchi), il gruppo si è distinto tra il 2021 e il 2022 per una serie di operazioni ad alto profilo contro Nvidia, Samsung, Okta, Microsoft e Uber, utilizzando principalmente tecniche di social engineering e SIM swapping piuttosto che exploit tecnici sofisticati. Dopo una serie di arresti nel 2022-2023, il gruppo sembrava smantellato. La ricomparsa nel 2026, questa volta sfruttando l’infrastruttura supply chain di TeamPCP come vettore di accesso iniziale, dimostra una capacità di adattamento e riorganizzazione che rende LAPSUS$ una minaccia ancora attiva.

Timeline dell’incidente


  • 23 marzo 2026: TeamPCP compromette le immagini Docker KICS e le estensioni VS Code; furto delle credenziali Checkmarx GitHub
  • Fine marzo – inizio aprile 2026: esfiltrazione massiva dei 95 GB di repository privati
  • 25 aprile 2026: LAPSUS$ pubblica il data dump sul dark web e rivendica l’attacco
  • 26 aprile 2026: Checkmarx pubblica un advisory confermando la violazione e bloccando l’accesso al repository compromesso
  • 29 aprile 2026: il dump viene diffuso pubblicamente in forum accessibili, aumentando il rischio di sfruttamento secondario delle chiavi API esposte


Implicazioni per gli utenti Checkmarx e i team DevSecOps


La violazione di Checkmarx solleva preoccupazioni su più livelli. In primo luogo, l’esposizione del codice sorgente dei motori di analisi potrebbe consentire ad attori malevoli di identificare potenziali vulnerabilità nelle logiche di scanning, aprendo la porta ad attacchi che bypassano o manipolano i risultati dell’analisi statica del codice. In secondo luogo, i team che hanno utilizzato immagini Docker KICS o le estensioni VS Code compromesse tra marzo e aprile 2026 devono considerarsi potenzialmente compromessi e procedere con un’indagine forensica.

Indicatori di Compromissione e azioni immediate

# Immagini Docker KICS compromesse (periodo a rischio: 23/03 - 26/04/2026)
checkmarx/kics:latest  # verificare hash con: docker inspect --format='{{.Id}}' checkmarx/kics:latest
checkmarx/kics:v1.7.x  # controllare con advisory ufficiale Checkmarx
# Credenziali da ruotare immediatamente se si è usato KICS Docker nel periodo a rischio:
# - Token GitHub con accesso ai repository
# - Chiavi API Checkmarx
# - Credenziali MongoDB/MySQL condivise con l'ambiente di sviluppo
# - Segreti nelle pipeline CI/CD (GitHub Actions, GitLab CI, Jenkins)
# Verifica estensioni VS Code compromesse:
# Controllare l'elenco completo nel security advisory ufficiale su checkmarx.com/blog/checkmarx-security-update-april-26/
# Log da analizzare per pull sospetti (pipeline CI/CD):
# grep -r "checkmarx/kics" .github/workflows/ .gitlab-ci.yml Jenkinsfile

Consigli per i difensori


L’attacco a Checkmarx è emblematico di una tendenza sempre più preoccupante: i tool di sicurezza stessi diventano vettori di attacco. È necessario verificare i log delle pipeline CI/CD tra il 23 marzo e il 26 aprile 2026 per identificare eventuali pull di immagini Checkmarx da Docker Hub. Qualsiasi segreto memorizzato nell’ambiente di sviluppo deve essere considerato compromesso e sostituito immediatamente. Le estensioni VS Code Checkmarx vanno rimosse e reinstallate da sorgenti verificate e firmate. Il monitoraggio del dark web nei prossimi mesi è raccomandato: i 95 GB esfiltrati contengono informazioni che potrebbero essere sfruttate per attacchi secondari a lungo termine.

Più in generale, questo incidente sottolinea l’urgenza di adottare il principio del least privilege nelle pipeline CI/CD: i processi automatizzati non dovrebbero avere accesso a credenziali di produzione. L’isolamento degli ambienti — sviluppo, staging, produzione — e la firma crittografica delle immagini container (tramite strumenti come Cosign e la policy enforcement con Kyverno o OPA) limitano significativamente il blast radius di compromissioni simili. Quando a essere attaccato è chi produce gli strumenti di difesa, l’unica risposta efficace è l’architettura zero-trust applicata anche all’infrastruttura DevSecOps.


Jenny’s Daily Drivers: Going 32-Bit With SliTaz In 2026


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

We’re used to seeing technologies move with the times, and it’s likely among Hackaday readers are the group who spend the most time doing that and are most aware of it. There’s one which we’ll all be aware of which has quietly slipped away for most of us almost without a word, I speak of course of 32-bit computing. For most of us that means 32-bit computing on x86 machines, and since the 64-bit x86 instruction set we all now use has been around for nearly a quarter century, its 32-bit ancestor is now ancient history.

In the world of software that means we’re now in an era of operating systems and browsers dropping 32-bit support, so increasingly keeping a 32-bit machine up to date will become a challenge. That sounds like something just painful and difficult enough to subject to a Daily Drivers piece, so just how practical is it to use a 32-bit machine for my daily work in 2026?

2005 Just Gave Me A Computer

My trusty Dell, showing the SliTaz desktopNot looking too bad for a 21 year old laptop.
On my desk I have a Dell Latitude D610. It was made in about 2005 in the days when Dells were solidly made, and with its 1.6GHz Pentium M and 2Gb of memory it represents roughly the final throw of the dice for a 32-bit Intel laptop. Just over a year later it would have been replaced by one of the Intel Core series with the 64-bit instructions grudgingly adopted from AMD, but at the time it was a respectably useful machine.

It came into my possession about eight years ago when I used it to test the Revbank bar tab software for my hackerspace, and for the past six years it’s languished unloved in my box there. It’s got an ancient Ubuntu distro on it, so my first task is to pick a 32-bit replacement from 2026. That’s now a dwindling selection, so it’s time to start digging though some minimalist distros. With the supply of those based on mainstream distros drying up as they drop 32-bit support, it’s time to look into more esoteric offerings. This fits well with the ethos of this series, we’re all about the unusual here.

Cutting out the mainstream based distros certainly narrows the field, and out of the promising contenders in the minimalist field, I went for SliTaz. It uses Busybox and the Openbox desktop, that runs from RAM. I was looking for good application support in the repos, and this distro has the things I need. Download it, stick it on a USB stick, and let’s see what it can do. I know one thing, I wouldn’t have been able to download that ISO in five seconds with the internet connection I had in 2005.

SliTaz, A Tiny Distro That’s Really Useful


With a few of the type of quirks you’ll always encounter with a new distro, the SliTaz instllation process was pretty painless. It required me to use Gparted to partition the spinning rust on the Dell, but otherwise the installation was mostly a case of filling in standard responses you’d find on any distro. Then it’s into the Openbox desktop environment. This thing is fast!
The Tazpanel application running the SliTaz installer.Installation is straightforward.
Graphical system administration is done through the Tazpanel application that as far as I can see uses the web browser, which soon had me connected to the internet and downloading GIMP so I could do my Hackaday work. The package library is comprehensive, which is pleasing to see. The default web browser is called Tazweb, which is modern enough to render most the sites I normally use, but which for some reason didn’t like Hackaday’s WYSIWYG editor so I was left writing in HTML source. It is quick though on this older hardware, something brought home to me when I downloaded Pale Moon. That browser is usable, but noticeably slow.

This was the first time using SliTaz for me, and I have to say I’m impressed. It’s small and fast compared to other full-fat distros I’ve used on machines of this age, and quirks aside, it’s easy to use and seems well supported. I’ve written most of this piece on it, and unlike some of the previous operating systems in this series, that has not been a painful experience. It has made the Dell into a useful machine again, one which while it’s no powerhouse, is at least no longer a piece of e-waste. There’s also a 64-bit version, making it a good choice for newer old hardware too. (The Raspberry Pi 1 port looks particularly interesting.)

Should You Though, Really?

Hackaday in the SliTaz browserIt does all the important stuff.
So what have I proved here? A 21 year old 32 bit machine is a bit slow but still usable here in 2026 with the right software, which is to my mind a testament to the skill and dedication of open source developers and maintainers for keeping this ancient architecture alive. Researching this piece though it’s very obvious that much of the software necessary for modern computing is slipping out of 32 bit support, so I have to question how much longer they can keep it up. Considering that this machine has about the same intrinsic monetary value as a Core2-based machine made a little over a year later which supports 64 bit code I have to concede that what I’ve just done is a fairly pointless exercise. It’s necessary to keep old hardware usable as long as possible, but when it’s lasted over two decades as this one has them maybe we should concede that it’s time to move on. Find a 64-bit laptop from 2007, by all means install 64-bit SliTaz if you want a quick and small distro, and move forward with many more years of software support.

In a way the real star of this piece is the Dell itself. It was a corporate laptop, then as far as I know it was used by the Men In Sheds that shares the building with MK Makerspace, and when they tossed it I nabbed it to play with RevBank. Saved by a piece of Dutch open source software it’s sat unloved for years, and yet it’s still reliable, its battery still holds almost useful charge, its keyboard is robust if a little worn, and its joints are still tight. It’s a shame the architecture is sliding out of relevance, this is almost a useful laptop!


hackaday.com/2026/04/30/jennys…

Cybersecurity & cyberwarfare ha ricondiviso questo.

Agent’s claims on #WhatsApp access spark security concerns
securityaffairs.com/191515/soc…
#securityaffairs #hacking #Meta

Foto di documenti su WhatsApp e archivi insicuri: il Garante privacy bacchetta hotel e B&B


@Informatica (Italy e non Italy)
Il Garante privacy ha ribadito alle associazioni di categoria del settore hospitality il divieto di conservare le copie dei documenti di identità degli ospiti oltre il tempo necessario alla comunicazione dei dati alle autorità di

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

Mini Shai-Hulud: TeamPCP compromette i pacchetti npm ufficiali di SAP in un attacco supply chain enterprise


@Informatica (Italy e non Italy)
Il gruppo TeamPCP ha compromesso i pacchetti npm ufficiali di SAP in un attacco supply chain denominato 'Mini Shai-Hulud': versioni malevole pubblicate il 29 aprile 2026 rubano credenziali AWS, Azure,


Mini Shai-Hulud: TeamPCP compromette i pacchetti npm ufficiali di SAP in un attacco supply chain enterprise


Il 29 aprile 2026, il gruppo TeamPCP ha compromesso i pacchetti npm ufficiali di SAP in quello che i ricercatori di Wiz hanno battezzato “Mini Shai-Hulud”: un attacco alla supply chain enterprise di estrema rilevanza che ha preso di mira gli ambienti di sviluppo e CI/CD di organizzazioni che utilizzano il Cloud Application Programming Model (CAP) e Cloud MTA di SAP. L’operazione si distingue per la sofisticazione del meccanismo di esfiltrazione e per la capacità di rubare credenziali da praticamente ogni sistema cloud aziendale utilizzato dagli sviluppatori colpiti.

SAP nell’occhio del ciclone: perché questa supply chain attack è critica


SAP è il backbone ERP di migliaia di aziende enterprise globali. Il suo Cloud Application Programming Model (CAP) è il framework ufficiale per costruire applicazioni cloud-native su SAP Business Technology Platform. Una compromissione dei pacchetti npm di SAP CAP non è, quindi, un attacco a una libreria open source di nicchia: è un’iniezione di malware nel cuore degli ambienti di sviluppo enterprise, con accesso diretto a credenziali di produzione, segreti CI/CD e infrastrutture cloud di organizzazioni Fortune 500.

La finestra temporale dell’attacco è stata precisa e calcolata: le versioni malevole dei pacchetti SAP sono state pubblicate su npm il 29 aprile 2026 tra le 09:55 UTC e le 12:14 UTC — un arco di circa due ore e mezza. Questo tipo di timing suggerisce un’operazione pianificata per massimizzare la finestra di esposizione prima che i team di sicurezza potessero reagire, sfruttando le ore mattutine dei fusi orari europei e americani durante le quali i sistemi CI/CD eseguono build automatizzate.

Anatomia dell’attacco: da preinstall script a credential stealer


Il meccanismo di attacco sfrutta una caratteristica legittima del registry npm: gli script preinstall, che vengono eseguiti automaticamente ogni volta che un pacchetto viene installato come dipendenza. I ricercatori di Socket e Wiz hanno ricostruito la catena di infezione in tre fasi distinte.

Fase 1 — Bootstrap con Bun: Lo script preinstall esegue un loader chiamato setup.mjs che scarica da GitHub il runtime JavaScript Bun. L’utilizzo di Bun anziché Node.js è un’indicazione tattica: Bun è meno monitorato dai tool di sicurezza aziendali ed è più difficile da rilevare in ambienti enterprise dove Node.js è già whitelistato. Questo scaricamento di un binary non verificato è di per sé sufficiente per classificare il pacchetto come malevolo.

Fase 2 — Execution payload offuscato: Il runtime Bun viene utilizzato per eseguire un payload denominato execution.js, pesantemente offuscato. Il payload implementa logiche di raccolta credenziali e meccanismi anti-analisi per complicare il reverse engineering.

Fase 3 — Esfiltrazione crittografata: I dati rubati vengono cifrati con una chiave RSA pubblica hardcoded nel malware e caricati su repository GitHub pubblici creati sull’account della stessa vittima — con la descrizione ironica “A Mini Shai-Hulud has Appeared” (riferimento al verme del deserto di Dune). Questa tecnica di esfiltrazione tramite GitHub è particolarmente insidiosa poiché il traffico verso github.com è raramente bloccato nelle reti aziendali.

Tipologia di credenziali rubate


Il credential stealer è progettato per aspirare qualsiasi segreto accessibile nell’ambiente dello sviluppatore o del pipeline CI/CD:

  • Token GitHub e npm — accesso ai repository e alle pipeline di deploy
  • GitHub Actions secrets — credenziali iniettate nei workflow di CI/CD
  • Chiavi SSH — accesso diretto a server e infrastruttura
  • Credenziali cloud: AWS (access key + secret), Azure (service principal), Google Cloud Platform (service account JSON), Kubernetes (kubeconfig)
  • Segreti CI/CD in memoria — variabili d’ambiente caricate nei processi attivi al momento dell’esecuzione


Attribuzione a TeamPCP: la chiave RSA come firma digitale


Wiz attribuisce l’operazione a TeamPCP con alta confidenza. L’elemento chiave è la riutilizzazione della stessa chiave RSA pubblica per cifrare i dati esfiltrati — la medesima chiave impiegata in precedenti compromissioni di librerie attribuite allo stesso gruppo. È un errore operativo significativo da parte degli attaccanti: la chiave di cifratura diventa di fatto una firma identificativa che collega tutte le campagne dello stesso operatore.

TeamPCP non è un nuovo arrivato nel panorama degli attacchi alla supply chain npm. Il gruppo ha già condotto operazioni simili contro altre librerie, dimostrando un interesse sistematico per l’ecosistema JavaScript enterprise e un pattern operativo consolidato: compromissione di pacchetti legittimi e ad alta fiducia, payload multistadio con downloader, esfiltrazione tramite servizi cloud legittimi.

Il pattern più ampio: tre supply chain attack in 48 ore


L’attacco ai pacchetti SAP non è avvenuto in isolamento. GitGuardian ha documentato come nelle stesse 48 ore abbiano colpito campagne analoghe su npm (il pacchetto tanstack contraffatto che esfiltrava file .env), PyPI e Docker Hub — suggerendo un’intensificazione coordinata delle operazioni di supply chain attack verso l’ecosistema di sviluppo software nel suo complesso. Questo tipo di attività “a grappolo” potrebbe indicare un mercato underground più attivo, o una risposta a opportunità specifiche emerse nell’ecosistema open source.

Indicatori di Compromissione (IoC)

# Pacchetti SAP npm compromessi (versioni malevole - 29 aprile 2026)
# Pubblicati tra 09:55 UTC e 12:14 UTC

# Indicatori infrastrutturali:
# - Loader: setup.mjs (scarica Bun runtime da GitHub)
# - Payload: execution.js (offuscato, eseguito via Bun)
# - Chiave RSA pubblica condivisa con altre campagne TeamPCP

# Pattern di esfiltrazione:
# - Dati caricati su repository GitHub pubblici della vittima
# - Descrizione repository: "A Mini Shai-Hulud has Appeared"
# - Dati cifrati con RSA prima dell'upload

# File target:
.env
.env.local
.env.production
~/.ssh/id_rsa
~/.aws/credentials
~/.kube/config

# Riferimenti:
# Socket: https://socket.dev/blog/sap-cap-npm-packages-supply-chain-attack
# Wiz: https://www.wiz.io/blog/mini-shai-hulud-supply-chain-sap-npm
# BleepingComputer: https://www.bleepingcomputer.com/news/security/official-sap-npm-packages-compromised-to-steal-credentials/

Raccomandazioni immediate per i difensori


Chi utilizza pacchetti SAP CAP o Cloud MTA nel proprio ambiente di sviluppo deve agire immediatamente su più fronti. Il primo passo è verificare le versioni installate nei propri progetti e disinstallare qualsiasi versione pubblicata il 29 aprile 2026: eseguire npm audit e confrontare le versioni con il changelog ufficiale SAP. In secondo luogo, è necessario trattare tutte le credenziali presenti negli ambienti di sviluppo e CI/CD come potenzialmente compromesse: ruotare token GitHub, chiavi AWS/Azure/GCP, credenziali npm e kubeconfig.

A livello organizzativo, questo attacco riporta all’attenzione la necessità di implementare policy di Software Composition Analysis (SCA) nei pipeline CI/CD, con blocco automatico di pacchetti che eseguono script preinstall o scaricano binary da sorgenti esterne. L’adozione di soluzioni come Socket, Wiz o Snyk per il monitoraggio in real-time delle dipendenze npm rappresenta oggi una misura non più opzionale per chi gestisce ambienti enterprise basati su Node.js.

Fonti: Socket Research Team, Wiz Security Blog, BleepingComputer, GitGuardian Blog — 29-30 aprile 2026.


Cybersecurity & cyberwarfare ha ricondiviso questo.

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

Linux Kernel Zero-Day “Copy Fail” (CVE-2026-31431) Grants Root Access on Every Major Distro Since 2017
#CyberSecurity
securebulletin.com/linux-kerne…
Cybersecurity & cyberwarfare ha ricondiviso questo.

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

Lazarus Group Targets macOS Users With Sophisticated “Mach-O Man” Four-Stage Malware Kit
#CyberSecurity
securebulletin.com/lazarus-gro…
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.

Mini Shai-Hulud: TeamPCP compromette i pacchetti npm ufficiali di SAP in un attacco supply chain enterprise
#CyberSecurity
insicurezzadigitale.com/mini-s…


Mini Shai-Hulud: TeamPCP compromette i pacchetti npm ufficiali di SAP in un attacco supply chain enterprise


Il 29 aprile 2026, il gruppo TeamPCP ha compromesso i pacchetti npm ufficiali di SAP in quello che i ricercatori di Wiz hanno battezzato “Mini Shai-Hulud”: un attacco alla supply chain enterprise di estrema rilevanza che ha preso di mira gli ambienti di sviluppo e CI/CD di organizzazioni che utilizzano il Cloud Application Programming Model (CAP) e Cloud MTA di SAP. L’operazione si distingue per la sofisticazione del meccanismo di esfiltrazione e per la capacità di rubare credenziali da praticamente ogni sistema cloud aziendale utilizzato dagli sviluppatori colpiti.

SAP nell’occhio del ciclone: perché questa supply chain attack è critica


SAP è il backbone ERP di migliaia di aziende enterprise globali. Il suo Cloud Application Programming Model (CAP) è il framework ufficiale per costruire applicazioni cloud-native su SAP Business Technology Platform. Una compromissione dei pacchetti npm di SAP CAP non è, quindi, un attacco a una libreria open source di nicchia: è un’iniezione di malware nel cuore degli ambienti di sviluppo enterprise, con accesso diretto a credenziali di produzione, segreti CI/CD e infrastrutture cloud di organizzazioni Fortune 500.

La finestra temporale dell’attacco è stata precisa e calcolata: le versioni malevole dei pacchetti SAP sono state pubblicate su npm il 29 aprile 2026 tra le 09:55 UTC e le 12:14 UTC — un arco di circa due ore e mezza. Questo tipo di timing suggerisce un’operazione pianificata per massimizzare la finestra di esposizione prima che i team di sicurezza potessero reagire, sfruttando le ore mattutine dei fusi orari europei e americani durante le quali i sistemi CI/CD eseguono build automatizzate.

Anatomia dell’attacco: da preinstall script a credential stealer


Il meccanismo di attacco sfrutta una caratteristica legittima del registry npm: gli script preinstall, che vengono eseguiti automaticamente ogni volta che un pacchetto viene installato come dipendenza. I ricercatori di Socket e Wiz hanno ricostruito la catena di infezione in tre fasi distinte.

Fase 1 — Bootstrap con Bun: Lo script preinstall esegue un loader chiamato setup.mjs che scarica da GitHub il runtime JavaScript Bun. L’utilizzo di Bun anziché Node.js è un’indicazione tattica: Bun è meno monitorato dai tool di sicurezza aziendali ed è più difficile da rilevare in ambienti enterprise dove Node.js è già whitelistato. Questo scaricamento di un binary non verificato è di per sé sufficiente per classificare il pacchetto come malevolo.

Fase 2 — Execution payload offuscato: Il runtime Bun viene utilizzato per eseguire un payload denominato execution.js, pesantemente offuscato. Il payload implementa logiche di raccolta credenziali e meccanismi anti-analisi per complicare il reverse engineering.

Fase 3 — Esfiltrazione crittografata: I dati rubati vengono cifrati con una chiave RSA pubblica hardcoded nel malware e caricati su repository GitHub pubblici creati sull’account della stessa vittima — con la descrizione ironica “A Mini Shai-Hulud has Appeared” (riferimento al verme del deserto di Dune). Questa tecnica di esfiltrazione tramite GitHub è particolarmente insidiosa poiché il traffico verso github.com è raramente bloccato nelle reti aziendali.

Tipologia di credenziali rubate


Il credential stealer è progettato per aspirare qualsiasi segreto accessibile nell’ambiente dello sviluppatore o del pipeline CI/CD:

  • Token GitHub e npm — accesso ai repository e alle pipeline di deploy
  • GitHub Actions secrets — credenziali iniettate nei workflow di CI/CD
  • Chiavi SSH — accesso diretto a server e infrastruttura
  • Credenziali cloud: AWS (access key + secret), Azure (service principal), Google Cloud Platform (service account JSON), Kubernetes (kubeconfig)
  • Segreti CI/CD in memoria — variabili d’ambiente caricate nei processi attivi al momento dell’esecuzione


Attribuzione a TeamPCP: la chiave RSA come firma digitale


Wiz attribuisce l’operazione a TeamPCP con alta confidenza. L’elemento chiave è la riutilizzazione della stessa chiave RSA pubblica per cifrare i dati esfiltrati — la medesima chiave impiegata in precedenti compromissioni di librerie attribuite allo stesso gruppo. È un errore operativo significativo da parte degli attaccanti: la chiave di cifratura diventa di fatto una firma identificativa che collega tutte le campagne dello stesso operatore.

TeamPCP non è un nuovo arrivato nel panorama degli attacchi alla supply chain npm. Il gruppo ha già condotto operazioni simili contro altre librerie, dimostrando un interesse sistematico per l’ecosistema JavaScript enterprise e un pattern operativo consolidato: compromissione di pacchetti legittimi e ad alta fiducia, payload multistadio con downloader, esfiltrazione tramite servizi cloud legittimi.

Il pattern più ampio: tre supply chain attack in 48 ore


L’attacco ai pacchetti SAP non è avvenuto in isolamento. GitGuardian ha documentato come nelle stesse 48 ore abbiano colpito campagne analoghe su npm (il pacchetto tanstack contraffatto che esfiltrava file .env), PyPI e Docker Hub — suggerendo un’intensificazione coordinata delle operazioni di supply chain attack verso l’ecosistema di sviluppo software nel suo complesso. Questo tipo di attività “a grappolo” potrebbe indicare un mercato underground più attivo, o una risposta a opportunità specifiche emerse nell’ecosistema open source.

Indicatori di Compromissione (IoC)

# Pacchetti SAP npm compromessi (versioni malevole - 29 aprile 2026)
# Pubblicati tra 09:55 UTC e 12:14 UTC

# Indicatori infrastrutturali:
# - Loader: setup.mjs (scarica Bun runtime da GitHub)
# - Payload: execution.js (offuscato, eseguito via Bun)
# - Chiave RSA pubblica condivisa con altre campagne TeamPCP

# Pattern di esfiltrazione:
# - Dati caricati su repository GitHub pubblici della vittima
# - Descrizione repository: "A Mini Shai-Hulud has Appeared"
# - Dati cifrati con RSA prima dell'upload

# File target:
.env
.env.local
.env.production
~/.ssh/id_rsa
~/.aws/credentials
~/.kube/config

# Riferimenti:
# Socket: https://socket.dev/blog/sap-cap-npm-packages-supply-chain-attack
# Wiz: https://www.wiz.io/blog/mini-shai-hulud-supply-chain-sap-npm
# BleepingComputer: https://www.bleepingcomputer.com/news/security/official-sap-npm-packages-compromised-to-steal-credentials/

Raccomandazioni immediate per i difensori


Chi utilizza pacchetti SAP CAP o Cloud MTA nel proprio ambiente di sviluppo deve agire immediatamente su più fronti. Il primo passo è verificare le versioni installate nei propri progetti e disinstallare qualsiasi versione pubblicata il 29 aprile 2026: eseguire npm audit e confrontare le versioni con il changelog ufficiale SAP. In secondo luogo, è necessario trattare tutte le credenziali presenti negli ambienti di sviluppo e CI/CD come potenzialmente compromesse: ruotare token GitHub, chiavi AWS/Azure/GCP, credenziali npm e kubeconfig.

A livello organizzativo, questo attacco riporta all’attenzione la necessità di implementare policy di Software Composition Analysis (SCA) nei pipeline CI/CD, con blocco automatico di pacchetti che eseguono script preinstall o scaricano binary da sorgenti esterne. L’adozione di soluzioni come Socket, Wiz o Snyk per il monitoraggio in real-time delle dipendenze npm rappresenta oggi una misura non più opzionale per chi gestisce ambienti enterprise basati su Node.js.

Fonti: Socket Research Team, Wiz Security Blog, BleepingComputer, GitGuardian Blog — 29-30 aprile 2026.


A Tractor From A Small Town Might Just Be The Catalyst For Ousting Machinery DRM


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

Odd things sometimes pop up in the feed of a Hackaday scribe, not hacks as such, but stories with a meaning in our community. One such that’s come our way from a variety of sources over the last week features Ursa Ag, a small machinery manufacturer based in Alberta, Canada. The reason they’re in the news is because they have gained bulging order books by taking on the likes of John Deere with a tractor more like the one their customers’ parents bought back in the ’80s or ’90s. It’s a basic machine without much in the way of electronics, and certainly without all the DRM lockdown that has made those big manufacturers so unpopular.

It’s clear that Hackaday isn’t in the business of shilling Canadian tractors, but it should be of interest to readers because it represents an alternative route to challenge the DRM lockdowns than the legal and consumer routes we’ve previously reported on. The Ursa Ag tractor may be as niche Albertan as a Corb Lund CD, but it’s not the tractor itself but the idea which matters. We doubt much sweat will be shed by John Deere execs over a tiny company out on the prairies making a basic spec tractor, but given that Ursa Ag customers are reported as buying them because they have no DRM, the prospect of larger upstart competitors taking note and offering machines without it may cause them some sleep loss. The free market is held up to outsiders as perhaps the most American of ideals, and for it to eventually prove to be the means by which something intended to limit it might be defeated, is sweet justice indeed.

We’ve reported extensively on the Deere tractor saga over the years, but perhaps the best illustration of the self-inflicted damage the brand has suffered through DRM comes in their older products being worth considerably more than their newer ones.


hackaday.com/2026/04/30/a-trac…

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 GPS è stato hackerato! Camion convinti di viaggiare… mentre spariscono nel nulla

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

A cura di Carolina Vivianti

#redhotcyber #news #sicurezzainformatica #cybersecurity #hacking #malware #gps

Cassazione: sequestro probatorio dello smartphone solo per acquisire dati mirati


@Informatica (Italy e non Italy)
La Cassazione si pronuncia sul sequestro probatorio di uno smartphone contenente informazioni e dati personali. Ecco la conclusione della Corte
L'articolo Cassazione: sequestro probatorio dello smartphone solo per acquisire dati mirati proviene da

How TTY Opened Up The Phones For The Hard of Hearing


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

The telephone was an invention that revolutionized human communication. No more did you have to physically courier a letter from one place to another, or send a telegram, or have a runner carry the message for you. Instead, you could have a direct conversation with another person a great distance away. All well and good if you can speak and hear, of course, but rather useless if you happen to be deaf.

Those hard of hearing were not left entirely out of the communication revolution, however. Well before IP switched networks and the Internet became a thing, there was already a way for the deaf to communicate over the plain old telephone network—thanks to the teletypewriter!

Over The Wires


The teletypewriter (TTY) has been around for a long time. The first device came into being in 1964, developed by James C. Marsters and Robert Weitbrecht, both deaf. Their idea was to create a method for deaf individuals to communicate over the phone network in a textual manner. To this end, the group sourced teleprinters formerly used by the US Department of Defense, and hooked them up with acoustic couplers that would allow them to mate with the then-ubiquitous AT&T Model 500 telephone. Thus, the TTY was born. A user could dial another TTY machine, and key in a message, which would print out at the other end. The receiving user could then respond in turn in the same manner.

A Miniprint 425 TDD device. Note the acoustic coupler on top, the VFD for displaying messages, the printer, and the SK and GA keys which automatically key in these regularly-used abbreviations. Credit: public domain
The early machine used simple frequency-shift keying to encode the characters of the alphabet and some basic control codes, allowing text messages to be sent back and forth via a regular analog telephone call. In the US, where the devices eventually became known as telecommunications device for the deaf (TDDs), the devices used an improved development of Baudot code (the USA-TTY variant of ITA-2) to send signals over the phone lines.

This involved representing characters with five bits, which was enough to cover the 26 characters of the English alphabet, plus 0-9 and a few control codes. Transmission rates were slow—typically just 45.5 to 50 baud. With a 5-bit code, this limited transmission to approximately 10 characters per second.
The sign on the left indicates a payphone with a TTY device attached. These were rare installs back in the landline era, and vanishingly few remain today. Credit: CC BY-SA 4.0
TTYs quickly caught on as a useful device for the deaf and hard of hearing, and developed its own norms similar to other textual telecommunications methods that came before. Users would key “GA” for “go ahead,” to indicate the other party could “speak” on the half-duplex link, as two users typing at the same time would lead to garbled messages. “SK” stood for “stop keying” to indicate the ending of a call. Abbreviations were common to save effort, such as “CU” (see you) and “TMW” (tomorrow).

Relay Service


At its heart, the TTY was a very useful device for allowing its users to communicate via textual means to others with compatible hardware. However, alone, a TTY could not allow a deaf user to communicate effectively with regular telephone users. To enable greater accessibility, many organizations developed telecommunications relay services.
TTY machines led to the establishment of relay services that allowed deaf users to make regular phone calls with assistance from an operator. Credit: screenshot, Australian National Relay Service
These first existed as a number that deaf TTY users could call in order to connect to a human operator with their own TTY machine. This operator would place calls on behalf of the deaf individual, speaking on their behalf to other parties based on the deaf user’s inputs to their TTY device. In turn, the operator would key out the responses from the called party so the deaf individual could read back the conversation.

The first relay service was established by Converse Communications in Connecticut in 1974. The concept was quickly picked up by many other telecommunications operators around the world to provide an accessibility aid to those who needed it. These days, relay services still exist, though a great many relay services now operate over IP-based systems rather than via phone lines and TTY devices.

Hanging On


TTY still exists to some degree out in the world today. There are still subscribers with analog phone lines, and the basic TTY technology still fundamentally works over these links. However, the rise of SMS text messaging and widespread Internet connectivity have somewhat negated a lot of use cases for TTY technology these days. There have also been cases where digital upgrades to the phone network have made TTY operation more difficult, though some efforts have been made to ensure compatibility in some networks, particularly for emergency uses.

Ultimately, TTY was a technology that brought telecommunications access to a greater number of people than ever before. Like the landline phone and the fax machine, it’s no longer such a feature of modern life. However, it was an important link to the world for many in the deaf and hard of hearing community, and was greatly valued for the connection and accessibility it provided.


hackaday.com/2026/04/30/how-tt…

Cybersecurity & cyberwarfare ha ricondiviso questo.

The CopyFail announcement and handling is one of the least defender-supporting I think I've ever seen.

Mitigations were extremely thin at launch, and haven't improved much, and are even brittle and misleading:

infosec.exchange/@tychotithonu…

They've also largely neglected most of the value of the feedback they're getting from defenders clamoring for useful intel. The GitHub repo is full of feedback about which distros are affected or unaffected ... and a day later, none of it has been used to update the list of affected versions in the main README (except for the RHEL made-up version fix)

And this exchange is painful:

github.com/theori-io/copy-fail…

"None of us are RH people so it wasn't caught" 😐 You had weeks do basic vetting, or find someone who would help you.

Theori seems to have to have intended this to be a showcase for their product. Instead, it has convinced me that I will never buy anything from them.

Edit: Will Dorman goes into more detail here, 100% agreed:
infosec.exchange/@wdormann/116…

#CopyFail #cve_2026_31431

Questa voce è stata modificata (1 mese fa)

reshared this

Cybersecurity & cyberwarfare ha ricondiviso questo.

#Morpheus non è il villain più sofisticato che abbia mai visto girare, forse però, oggi è quello che mi preoccupa di più.
Perché non ha bisogno di 0day da gozzzzzilioni di dollari, basta un SMS ben scritto e un utente che si fida del suo operatore (ho imparato che fidarsi è bene ma..).

"I know kung fu!"
No Neo, non lo sai. E neanche la maggior parte degli utenti sa che quella finta app di aggiornamento ha appena consegnato il (loro) telefono a qualcuno.

#Pegasus ha fatto scalpore perché ha i big names, ma Morpheus è il prodotto entry level dello stesso mercato - mercato, tra l'altro, in piena espansione.
E in questo bel mercato ricco, la domanda sorge spontanea: "chi ha commissionato Morpheus, e perché nessuno risponde di niente?"

Oramai sappiamo che la sorveglianza digitale di massa non è fantascienza distopica ma un settore da miliardi, con sales deck e LinkedIn aziendale.

Benvenuti nella zona grigia (o nella giugla, a seconda delle preferenze musicali 😎)

@securityaffairs cybersecurity360.it/news/spywa…

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 Criminali si sono hackerati da soli! L’errore di un’AI espone 345.000 carte di credito

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

A cura di Chiara Nardini

#redhotcyber #hacking #cti #ai #online #it #cybercrime #cybersecurity #technology #news

Cybersecurity & cyberwarfare ha ricondiviso questo.

Sources: the White House opposes Anthropic's plan to expand access to Mythos to 70 additional companies and organizations because of concerns about security (Wall Street Journal)

wsj.com/tech/ai/white-house-op…
techmeme.com/260429/p65#a26042…

reshared this

Transcribing the Source of the First DOS for the IBM PC


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

Doing software archaeology can be a harrowing task, as rarely do you find complete snapshots of particular versions of software. Case in point the development of MS-DOS – also known as IBM PC DOS – from 86-DOS, which recently got a lucky break in the form of printed source listings. These printouts come courtesy of [Tim Paterson], the creator of 86-DOS and of MS-DOS during his time working for Microsoft.

These code listings contain the sources of the 86-DOS 1.00 kernel, multiple development snapshots, and also listings for utilities like CHKDSK. These printed listings additionally contain many handwritten notes, making transcribing it into working source code somewhat of a chore. The results can be found on the GitHub project page, with the original scans available on Archive.org.

Of the ten bundles of continuous feed paper prints all but two have been transcribed so far, though with the various DOS kernels and the Seattle Computer Products (SCP) assembler source already ready for compilation. This includes 86-DOS 1.00, MS-DOS 1.25 and PC-DOS 1.00-dev, requiring the same SCP assembler to create a binary.

In the project page README a number of blog posts are also linked that add even more technical detail. Anyone who wants to pitch in with transcribing and/or testing recovered source code is welcome to do so.


hackaday.com/2026/04/30/transc…

Spyware Morpheus: dentro il lato oscuro della sorveglianza globale


@Informatica (Italy e non Italy)
Morpheus è uno spyware che si presenta come un’applicazione innocua ma, una volta installato, consente un controllo completo del dispositivo. Nuovo elemento di quella zona grigia, alimentata da interessi economici miliardari e da un ecosistema globale poco regolato, in cui si

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

GLITTER CARP e SEQUIN CARP: la Cina spia giornalisti e attivisti con phishing mirato e OAuth abuse


@Informatica (Italy e non Italy)
Il Citizen Lab svela GLITTER CARP e SEQUIN CARP, due gruppi hacker allineati con la Cina che colpiscono giornalisti ICIJ e attivisti uiguri, tibetani e hongkonghesi con campagne di phishing sofisticate e abuse di OAuth


GLITTER CARP e SEQUIN CARP: la Cina spia giornalisti e attivisti con phishing mirato e OAuth abuse


Si parla di:
Toggle

Il Citizen Lab dell’Università di Toronto ha pubblicato un rapporto dettagliato che svela due distinti gruppi di hacker allineati con la Repubblica Popolare Cinese — denominati GLITTER CARP e SEQUIN CARP — responsabili di una campagna sistematica di sorveglianza digitale e phishing contro giornalisti investigativi, attivisti uiguri, tibetani, taiwanesi e hongkonghesi. La ricerca, condotta in collaborazione con l’International Consortium of Investigative Journalists (ICIJ), rappresenta un’ulteriore conferma della pervasività della repressione digitale transnazionale (DTR) orchestrata da Pechino.

Il contesto: la repressione digitale transnazionale della Cina


La Cina ha una lunga storia di persecuzione dei propri oppositori all’estero. Dagli anni ’90, le autorità di Pechino hanno minacciato, intimidito e fisicamente attaccato cittadini cinesi residenti all’estero che esprimevano dissenso verso il Partito Comunista. Nel corso dei decenni, la platea dei bersagli si è ampliata per includere esponenti delle diaspore tibetana, uigura, taiwanese e hongkonghese — i cosiddetti “Cinque Veleni” secondo la terminologia del CCP — oltre ai praticanti del Falun Gong e ai giornalisti che ne documentano le attività.

Il rapporto del Citizen Lab (Report No. 193, pubblicato il 27 aprile 2026) analizza come questa repressione si sia evoluta verso un modello di Military-Civil Fusion: attacchi state-sponsored eseguiti da contractor civili privati, con una netta divisione del lavoro tra i vari gruppi coinvolti. GLITTER CARP e SEQUIN CARP rappresentano due nodi distinti di questa rete, con TTP differenti ma finalità complementari.

GLITTER CARP: phishing massivo e furto di credenziali email


GLITTER CARP è attivo almeno dall’aprile 2025 e conduce una campagna di phishing ad ampio spettro, ma chirurgicamente mirata in termini di selezione delle vittime. Il gruppo ha colpito il World Uyghur Congress, lo Uyghur Human Rights Project (UHRP), TibCERT (la rete di risposta agli incidenti per la comunità tibetana), il media taiwanese Watchout e numerosi attivisti individuali come Carmen Lau, figura di spicco dell’attivismo hongkonghese.

Le tecniche adottate rivelano un’accurata preparazione operativa. In un caso emblematico, l’attivista uiguro-canadese Mehmet Tohti ha ricevuto un messaggio apparentemente proveniente da un noto regista uiguro, con una richiesta di visionare un documentario in anteprima. Il link non conduceva ad alcun video, ma a una pagina di login Google contraffatta. Il Citizen Lab ha inoltre identificato l’uso sistematico di tracking pixel nascosti nelle email di phishing, per verificare che il messaggio venisse aperto prima di procedere con la fase successiva dell’attacco.

L’infrastruttura di GLITTER CARP è stata documentata anche da Proofpoint, che ha osservato il riuso degli stessi domini e delle stesse identità impersonate in attacchi contro molteplici target. Il Citizen Lab ha identificato oltre cento domini correlati, alcuni dei quali probabilmente impiegati in operazioni non ancora rese pubbliche. L’obiettivo primario del gruppo sembra essere l’accesso iniziale ad account email, suggerendo un contratto specializzato all’interno del sistema Military-Civil Fusion che delega la compromissione dei dispositivi ad altri attori.

SEQUIN CARP: OAuth abuse e spionaggio dei giornalisti ICIJ


SEQUIN CARP opera con metodologie più sofisticate e ha come bersaglio principale i giornalisti dell’ICIJ impegnati nell’indagine “China Targets” — un progetto che documenta le pratiche di repressione transnazionale del CCP. La giornalista Scilla Alecci, coordinatrice del progetto, è stata oggetto di almeno tre tentativi di compromissione tra giugno 2025 e marzo 2026.

Il vettore d’attacco distintivo di SEQUIN CARP è il phishing OAuth: anziché rubare password, il gruppo induce le vittime a concedere autorizzazioni di accesso a email e calendario a un’applicazione di terze parti apparentemente legittima. Questa tecnica è particolarmente insidiosa perché:

  • Non richiede la conoscenza della password della vittima
  • Il token OAuth mantiene l’accesso anche dopo un cambio di password
  • L’accesso persiste finché la vittima non revoca manualmente il permesso dall’elenco delle app autorizzate
  • Le attività di lettura delle email non lasciano tracce nei log di accesso tradizionali

Per rendere credibili i propri approcci, SEQUIN CARP costruisce personas elaborate basate su narrative reali. In un caso, gli attaccanti hanno impersonato Bai Bin, un ex funzionario di un tribunale di Pechino la cui storia era già stata riportata da media cinesi, usando la sua identità per avvicinare la giornalista Alecci con una richiesta di informazioni apparentemente plausibile. Nonostante le capacità tecniche avanzate, il gruppo ha commesso errori operativi significativi che hanno permesso al Citizen Lab di tracciarne l’infrastruttura.

Attribuzione e implicazioni geopolitiche


Il Citizen Lab valuta con alta confidenza che entrambi i gruppi operino in favore della Repubblica Popolare Cinese, inserendosi nel pattern più ampio di repressione digitale transnazionale documentato negli ultimi anni. La coesistenza di due attori distinti con TTP differenti ma target sovrapposti suggerisce un ecosistema di contractor specializzati che risponde a mandati governativi specifici — un modello coerente con il sistema Military-Civil Fusion del governo cinese.

Proofpoint aveva già documentato attività correlate a GLITTER CARP contro altri soggetti legati agli interessi di Pechino, rafforzando l’ipotesi di una campagna coordinata e continuativa piuttosto che di operazioni episodiche. La duplice attenzione sull’ICIJ — con due attori separati che perseguono strategie diverse — evidenzia quanto l’organizzazione e i suoi giornalisti siano percepiti come minacce significative dalla leadership cinese.

Indicatori di Compromissione (IoC)

# Infrastruttura GLITTER CARP (domini impersonation identificati dal Citizen Lab)
# Categorie principali di impersonation:
# - Servizi Google (login, accounts, security-alerts)
# - Pagine ICIJ false
# - Profili di attivisti noti impersonati

# Tattiche SEQUIN CARP - OAuth Abuse
# Endpoint di autorizzazione OAuth abusati per accesso persistente a Gmail
# Tipologia di permessi richiesti: mail.read, calendar.readonly
# Vettore: email di spear-phishing con link a pagina di consent OAuth fake

# Tracking pixel:
# - Pixel nascosti nelle email per confermare apertura messaggio
# - Utilizzati come trigger per avanzamento attacco

# Referenza report completo:
# https://citizenlab.ca/research/how-chinese-actors-use-impersonation-and-stolen-narratives-to-perpetuate-digital-transnational-repression/

Come proteggersi: raccomandazioni per i difensori


Il Citizen Lab fornisce indicazioni pratiche per chi opera in ambienti ad alto rischio. In primo luogo, è fondamentale effettuare revisioni periodiche delle applicazioni OAuth autorizzate nel proprio account Google o Microsoft, revocando immediatamente qualsiasi accesso non riconosciuto o non più necessario. L’uso di chiavi di sicurezza hardware (FIDO2/WebAuthn) come secondo fattore di autenticazione rappresenta la misura più efficace contro i tentativi di phishing tradizionali, poiché il token fisico non può essere replicato su siti contraffatti.

Per i giornalisti e gli attivisti ad alto rischio, il Citizen Lab raccomanda l’adozione di strumenti come Access Now’s Digital Security Helpline e una formazione specifica sui pattern di spear-phishing legati alla repressione cinese. La verifica dell’identità dei contatti attraverso canali alternativi prima di cliccare su qualsiasi link — anche apparentemente proveniente da persone conosciute — rimane la misura preventiva più critica in questo contesto operativo.

Fonte primaria: Citizen Lab Report No. 193, “Tall Tales: How Chinese Actors Use Impersonation and Stolen Narratives to Perpetuate Digital Transnational Repression”, 27 aprile 2026. In collaborazione con ICIJ.


Gli attacchi cyber si stanno spostando sull’edge


@Informatica (Italy e non Italy)
Il report di TrendAI accende i riflettori sulle nuove tecniche adottate dagli hacker di stato. I gruppi APT guidano il cambiamento sfruttando sempre più spesso le vulnerabilità di dispositivi edge e l’adozione dell’AI rischia di peggiorare la situazione
L'articolo Gli attacchi cyber si stanno spostando sull’edge

Cybersecurity & cyberwarfare ha ricondiviso questo.

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

Azure Data Studio è in pensione: migra il tuo workflow Azure SQL su VS Code in 10 minuti
#tech
spcnet.it/azure-data-studio-e-…
@informatica


Azure Data Studio è in pensione: migra il tuo workflow Azure SQL su VS Code in 10 minuti


Se stai ancora aprendo Azure Data Studio per lavorare con Azure SQL, è arrivato il momento di fare il passo. Azure Data Studio (ADS) è andato ufficialmente in pensione il 6 febbraio 2025, e il supporto è terminato il 28 febbraio 2026. Microsoft ha indicato Visual Studio Code con l’estensione MSSQL come percorso ufficiale consigliato.

Questa guida ti aiuta a ripristinare rapidamente la produttività in VS Code: importare il setup esistente, recuperare le scorciatoie familiari come F5, e far funzionare SQL Database Projects per gestire le modifiche allo schema con sicurezza.

Perché questa migrazione conta per gli sviluppatori Azure SQL


Eseguire query è solo una parte del lavoro. La maggior parte dei team ha bisogno di workflow ripetibili per la revisione delle modifiche allo schema, la validazione in CI, e i deployment più sicuri. SQL Database Projects supporta questo stile di lavoro con “schema as code”, build validation, e un’esperienza di pubblicazione guidata direttamente in VS Code.

Rispetto ad Azure Data Studio, VS Code offre:

  • Un ecosistema di estensioni molto più ricco e aggiornato
  • Integrazione nativa con GitHub Copilot per l’assistenza SQL
  • Supporto per SQL database in Microsoft Fabric
  • Un editor più potente con refactoring, IntelliSense avanzato, e integrazione Git integrata


Step 1: Installa gli strumenti SQL essenziali per VS Code


Dalla Marketplace di VS Code, installa questi tre componenti:

Estensione MSSQL


Il tuo principale strumento per query, connessioni e workflow con il database. Cerca “SQL Server (mssql)” nel VS Code Marketplace. Questa estensione gestisce le connessioni ai server SQL Server, Azure SQL Database, Azure SQL Managed Instance e SQL database in Microsoft Fabric.

SQL Database Projects


Aggiunge il sistema di progetto e il workflow di build/publish per “schema as code”. Cerca “SQL Database Projects” nel Marketplace. Con questa estensione puoi organizzare oggetti SQL in un progetto versionabile, validare la struttura del database prima del deploy, e pubblicare in modo controllato.

.NET 8 SDK


SQL Database Projects dipende dal .NET SDK per la build. Installalo da dotnet.microsoft.com prima del primo build. L’estensione ti avviserà se manca, ma averlo pronto evita un riavvio aggiuntivo.

Step 2: Importa il tuo setup ADS esistente


L’estensione MSSQL include un ADS Migration Toolkit che trasferisce le tue connessioni salvate, i gruppi di connessioni, le impostazioni e i binding dei tasti in un unico flusso guidato. Apri l’estensione e segui il wizard.

Ripristinare F5 come abitudine muscolare


Se sei abituato a premere F5 per eseguire una query in Azure Data Studio, installa l’estensione MSSQL Database Management Keymap. Aggiunge i binding di tasti in stile ADS, incluso F5 per eseguire una query. Per l’elenco completo, consulta la documentazione “Customize keyboard shortcuts”.

Step 3: Configurare SQL Database Projects end-to-end


Questa è la parte che rende il workflow davvero solido. Segui questi passaggi nell’ordine:

1. Crea o apri un progetto SQL


Apri una cartella di progetto SQL esistente in VS Code, oppure creane uno nuovo tramite i comandi SQL Database Projects nell’editor. I file .sqlproj sono compatibili con SSDT, quindi puoi aprire progetti esistenti direttamente.

2. Esegui prima la build


Il primo traguardo deve essere una build pulita. Confermare che la toolchain è configurata correttamente prima di tentare un deploy è fondamentale. Eventuali errori di sintassi o riferimenti mancanti emergono qui, non in produzione.

3. Pubblica tramite il Publish Dialog


Fai clic destro sul progetto nel pannello Database Projects, seleziona Publish, configura il target, controlla il deployment script generato, e seleziona Publish per deployare.

La preview dello script è il punto che rende questo workflow affidabile per uso serio: vedi esattamente quale T-SQL verrà eseguito sul database prima che accada. Niente sorprese.

Problemi comuni e soluzioni


.NET SDK non trovato: Se la prima build non completa, verifica che il .NET SDK sia installato e che VS Code riesca a trovarlo. Questo è il problema più comune al primo avvio.

Target platform mismatch: Se il comportamento di publish è diverso da quello atteso, controlla il target platform del progetto nelle impostazioni .sqlproj. Molti problemi di publish dipendono dalla configurazione del progetto, non dal database in sé.

Lavorare con SQL database in Microsoft Fabric


La stessa configurazione VS Code si applica a SQL database in Microsoft Fabric, con un’aggiunta: inizia dal portale Fabric per collegare il database a Git prima di aprire il progetto localmente in VS Code. Questo garantisce che il file di progetto sia configurato correttamente per Fabric.

Item templates: per chi arriva da SSDT


Se vieni da SSDT, i template di elementi in SQL Database Projects generano stub consistenti per tabelle, stored procedure, view e altri oggetti comuni. Fai clic destro sul progetto nel pannello Database Projects e seleziona Add Item per iniziare.

Primi passi consigliati


Prova questo ciclo completo con qualsiasi schema di database piccolo:

  1. Crea o apri un SQL project
  2. Esegui la build
  3. Pubblica con script preview abilitato
  4. Apporta una modifica allo schema, ricompila, e pubblica di nuovo

Dopo questo ciclo, il workflow ti sembrerà naturale come quello di Azure Data Studio — con in più la potenza dell’ecosistema VS Code.

Conclusione


Azure Data Studio ha avuto la sua era, ma VS Code con l’estensione MSSQL è oggi il tool ufficiale e più potente per lavorare con Azure SQL. L’importazione del setup esistente richiede pochi minuti grazie all’ADS Migration Toolkit, e SQL Database Projects porta il workflow di schema management a un livello superiore rispetto a quanto era possibile in ADS.

Chi lavora con Azure SQL, SQL Server, o SQL database in Microsoft Fabric troverà in VS Code un ambiente più ricco e costantemente aggiornato. La transizione vale lo sforzo.

Fonte originale: Azure Data Studio is retired: Move your Azure SQL workflow to VS Code in 10 minutes — Iqra Shaikh, Microsoft Azure SQL Dev Corner (27 aprile 2026)


Cybersecurity & cyberwarfare ha ricondiviso questo.

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

Europol Dismantles €50 Million Investment Fraud Network Operating Corporate-Style Scam Call Centres in Albania
#CyberSecurity
securebulletin.com/europol-dis…
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 pulsante di emergenza: revoca immediata dei token in .NET 10 con Duende IdentityServer
#tech
spcnet.it/il-pulsante-di-emerg…
@informatica


Il pulsante di emergenza: revoca immediata dei token in .NET 10 con Duende IdentityServer


Immagina questo scenario da incubo: il telefono di un cliente bancario viene rubato, l’app mobile è già autenticata, e il ladro ha pieno accesso al suo conto. Il supporto riceve la chiamata disperata. Ogni secondo conta. Quanto tempo ci vuole per revocare quella sessione attiva e mettere al sicuro i fondi?

Se stai usando JWT self-contained standard, la risposta onesta potrebbe essere “fino a un’ora”, a seconda della durata di validità del token. Non è accettabile. Vediamo come i Reference Token ti forniscono un vero pulsante di emergenza per queste situazioni, e come configurarli con Duende IdentityServer in .NET 10.

Il problema dei JWT self-contained


I JWT self-contained sono il cavallo di battaglia dell’autorizzazione moderna. Trasportano tutte le claim di cui un’API ha bisogno direttamente nel token. Nessuna query al database, nessuna chiamata al provider di identità. L’API valida la firma, controlla la scadenza, e il gioco è fatto. È elegante e performante.

Ma questa natura self-contained è un’arma a doppio taglio. Una volta emesso un JWT, il provider di identità non ha più nulla da dire su di esso. Il token è valido fino a quando la claim exp non dice il contrario, tipicamente 5-60 minuti. Se un dispositivo viene rubato, un account compromesso, o una minaccia rilevata, non puoi revocare quel token. Sei costretto ad aspettare che scada.

Per molte applicazioni questo compromesso è accettabile. Per ambienti ad alta sicurezza come banking, sanità o sistemi governativi, è un gap che non puoi permetterti.

Reference Token: premere il pulsante


I Reference Token ribaltano il modello. Invece di incorporare tutte le claim direttamente nel token, IdentityServer memorizza il contenuto del token lato server nel suo persisted grant store e consegna al client un identificatore opaco (un “handle”). Quando un’API riceve questo handle, chiama l’endpoint di introspection di IdentityServer per validare il token e recuperare le claim.

Questo cambia tutto. Poiché i dati del token risiedono sul server, puoi cancellarli in qualsiasi momento. La revoca è immediata. La prossima volta che l’API chiama l’endpoint di introspection, riceve "active": false, e l’accesso viene negato. Niente attese di scadenza, niente token obsoleti in circolazione.

Il compromesso? Ogni chiamata API richiede un round-trip verso l’endpoint di introspection. Per API pubbliche su scala internet, è una preoccupazione. Per servizi interni e ambienti ad alta sicurezza, è un prezzo ragionevole per la capacità di staccare la spina istantaneamente.

Configurare i Reference Token in IdentityServer


Passare a Reference Token per un client richiede una singola riga di configurazione. Quando definisci il client in Duende IdentityServer, imposta la proprietà AccessTokenType:

new Client
{
    ClientId = "banking_app",
    ClientSecrets = { new Secret("secret".Sha256()) },
    AllowedGrantTypes = GrantTypes.Code,

    // Questa è la riga chiave
    AccessTokenType = AccessTokenType.Reference,

    AllowOfflineAccess = true,
    RedirectUris = { "https://banking.example.com/signin-oidc" },
    AllowedScopes = { "openid", "profile", "accounts.read", "transfers.write" }
};

I token emessi per questo client saranno ora handle opachi invece di JWT self-contained.

Configurare l’API per l’introspection


La tua API deve sapere come validare questi token opachi. Invece del (o in aggiunta al) classico JWT validation, configuri l’introspection OAuth 2.0. Prima, definisci un API Resource con un secret:

new ApiResource("banking_api")
{
    Scopes = { "accounts.read", "transfers.write" },
    ApiSecrets = { new Secret("api_secret".Sha256()) }
};

Poi nel Program.cs della tua API, registra l’handler di introspection:
builder.Services.AddAuthentication("token")
    .AddOAuth2Introspection("token", options =>
    {
        options.Authority = "https://identity.banking.example.com";
        options.ClientId = "banking_api";
        options.ClientSecret = "api_secret";
    });

Se devi supportare sia JWT che Reference Token (magari durante una migrazione), puoi registrare entrambi gli handler e usare il forwarding per instradare i token a quello corretto:
builder.Services.AddAuthentication("token")
    .AddJwtBearer("token", options =>
    {
        options.Authority = "https://identity.banking.example.com";
        options.Audience = "banking_api";
        options.TokenValidationParameters.ValidTypes = ["at+jwt"];
        options.ForwardDefaultSelector = Selector.ForwardReferenceToken("introspection");
    })
    .AddOAuth2Introspection("introspection", options =>
    {
        options.Authority = "https://identity.banking.example.com";
        options.ClientId = "banking_api";
        options.ClientSecret = "api_secret";
    });

Revocare un token


Quando quella chiamata disperata arriva, il tuo sistema di supporto (o una pipeline automatica di rilevamento minacce) può revocare il token immediatamente usando l’endpoint di revocation di IdentityServer, che implementa la RFC 7009:

using Duende.IdentityModel.Client;

var client = new HttpClient();
var result = await client.RevokeTokenAsync(new TokenRevocationRequest
{
    Address = "https://identity.banking.example.com/connect/revocation",
    ClientId = "banking_app",
    ClientSecret = "secret",
    Token = stolenAccessToken
});

if (result.IsError)
{
    logger.LogError("Token revocation failed: {Error}", result.Error);
}

Una volta revocato, il token viene rimosso dal persisted grant store. La prossima richiesta di introspection da qualsiasi API confermerà che il token non è più attivo. L’accesso è tagliato.

Non dimenticare: dovresti anche revocare il refresh token dell’utente per impedire al client di ottenere silenziosamente un nuovo access token:

await client.RevokeTokenAsync(new TokenRevocationRequest
{
    Address = "https://identity.banking.example.com/connect/revocation",
    ClientId = "banking_app",
    ClientSecret = "secret",
    Token = refreshToken
});

Nota: sia l’introspection che la revocation emettono eventi di audit che puoi usare per implementare log di audit nei settori regolamentati.

Quando usare i Reference Token


I Reference Token non sono un sostituto universale dei JWT. Brillano in scenari specifici:

  • La revoca immediata è un requisito imprescindibile (banking, sanità, sistemi compliance-driven)
  • Comunicazione service-to-service interna dove il round-trip di introspection è trascurabile
  • Operazioni ad alto rischio dove il beneficio di sicurezza supera il costo in performance

Per API pubbliche su larga scala dove la latenza di revoca è accettabile, i JWT self-contained con breve durata rimangono una scelta solida. Puoi anche mixare i due approcci: Reference Token per client sensibili e JWT per quelli a minor rischio, tutto all’interno dello stesso deployment IdentityServer.

Conclusione


Ogni architettura di sicurezza implica compromessi. I JWT self-contained scambiano la revocabilità per la performance. I Reference Token scambiano la performance per il controllo. Per gli ambienti dove “aspetta che scada” non è una risposta accettabile, i Reference Token con Duende IdentityServer ti forniscono un vero pulsante di emergenza.

L’implementazione è semplice: una proprietà sul client, un handler di introspection sull’API, e una chiamata di revocation quando devi staccare la spina. Quando accadono incidenti di sicurezza — e accadranno — sarai felice di averlo configurato.

Fonte originale: The Emergency Stop Button – Implementing Immediate Token Revocation in .NET 10 — Khalid Abuhakmeh, Duende Software (28 aprile 2026)


Cybersecurity & cyberwarfare ha ricondiviso questo.

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

SonicWall SonicOS Flaws Let Attackers Bypass Firewall Access Controls and Trigger Denial of Service
#CyberSecurity
securebulletin.com/sonicwall-s…
Cybersecurity & cyberwarfare ha ricondiviso questo.

#Meta accused of violating #DSA by failing to safeguard minors
securityaffairs.com/191511/law…
#securityaffairs #hacking #EU
Cybersecurity & cyberwarfare ha ricondiviso questo.

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

Uno strumento basato sull'intelligenza artificiale, nato per individuare le violazioni dei marchi sui social, è stato utilizzato per mettere a tacere i critici del SXSW

Il SXSW, la conferenza annuale su tecnologia, musica e cinema, ha usato BrandShield , un servizio di "protezione dai rischi digitali" per automatizzare il processo di identificazione e rimozione dei post sui social media che fanno un uso improprio dei marchi registrati per eliminare il dissenso

404media.co/sxsw-used-ai-power…

@pirati


SXSW Used AI-Powered Trademark Tool To Censor Dissent on Instagram


An AI-powered tool designed to target trademark violations on social media was used to silence critics of SXSW, the massive annual tech, music and film conference in Austin, Texas.

Each year in March, SXSW takes over Austin. This year, thanks to the demolition of the city’s aging convention center, events sprawled to more locations than usual, from hotel ballrooms to vacant lots. But the character of SXSW has changed, growing more corporate and less accessible since its relatively humble origins in 1987, and today it has numerous detractors. This year some of those dissenting voices found themselves targeted by BrandShield, a “digital risk protection” service that claims to use artificial intelligence to automate the process of identifying and removing social posts that misuse trademarks.

Among the groups to receive a social media takedown notice was Vocal Texas, a nonprofit dedicated to ending homelessness, HIV, poverty and the war on drugs. On March 12, members of the group set up a mock encampment in downtown Austin, to draw attention to the possessions that unhoused people can lose during “sweeps,” when police and city officials clear out and destroy or confiscate their tents and other lifesaving supplies.
An example of an image deleted by Instagram
An Instagram post by Vocal Texas read, “SXSW means unhoused Austinites in downtown face encampment sweeps, tickets and arrests while the City makes room for billionaires and corporations to rake in profits.” The accompanying image promised an art installation called “Sweep the Billionaires,” and does not use SXSW’s logos.

Even so, the mere mention of SXSW was apparently enough to flag BrandShield’s trademark detection service, resulting in the post’s fully automated removal from Instagram. Cara Gagliano, a senior staff attorney who specializes in trademark and intellectual property law at the Electronic Frontier Foundation said that posts like these do not violate SXSW’s trademark.

“You’re allowed to use a company’s name to talk about the company, right?” Gagliano told 404 Media. “How else are you going to do it?”

Gagliano noted that trademark law has specific carveouts for exactly this kind of critical speech. “Examples like that, where it's not (for example) advertising a concert with a name similar to South by Southwest ... are pretty clearly over-enforcement,” she said.

EFF interceded in March 2024 when the Austin for Palestine coalition received a cease and desist letter from SXSW, accusing them of infringing on the conference’s trademark and copyright. The coalition, which was involved with organizing successful protests against the festival’s sponsorship by the U.S. military, had made social media posts featuring SXSW’s trademarked arrow logo reimagined with bloodstains, fighter jets, and other warlike imagery. The EFF wrote a letter on the coalition’s behalf, and the group never heard from SXSW again.

But Gagliano explained that this situation is different from the takedown notices sent by BrandShield. “When it's a threat sent to ... the person who made the allegedly infringing use, them going away is a victory for the client because nothing bad happens to them, but when you have these takedowns ... [while] it's good that they didn't go even further and file a lawsuit, they also don't have any incentive to retract the complaint, and so the content stays down.”

This year, many of the protests and “counter events” were organized by a very loosely associated coalition of groups called Smash By Smash West, which included Vocal Texas along with many others, from musicians and independent movie directors to event venues.

404 Media reached a representative of Smash By Smash West via Signal who used the name “Burnice.” We agreed to protect their anonymity, but verified that they were involved with the organizing of Smash By events. Operating since 2024, Smash By has no leaders and essentially anyone can organize an event under its umbrella. This year, there were over 100 events, according to Burnice. “It is a decentralized call to action and a platform that enables promotion and connecting together all of these different events.”

Smash By Smash West provided us with dozens of screenshots of Instagram takedown notices as well as many of the posts which had been removed.

BrandShield’s software enables mass reporting of potentially infringing content, with reports in turn evaluated by Instagram’s automated moderation systems. Despite their obviously automated nature, BrandShield claims to use a “dedicated enforcement team of IP lawyers” to ensure that takedowns are “timely, targeted and fully compliant.”

The BrandShield website reads, “Whether it's a distorted logo, a counterfeit image, or a cloned storefront, our proprietary image recognition technology scans marketplaces, social media, paid media, and mobile environments to catch threats at the source.”



However, despite these assurances, it seems clear that BrandShield’s trademark targets with a very broad brush, and seems incapable of distinguishing between trademark violations and protected free speech. Although BrandShield initially connected us with their public relations department, they did not respond to repeated requests for comment including an emailed list of inquiries.

Instagram’s automatically generated takedown notices include the sentence, “If you think this content shouldn’t have been removed from Instagram, you can contact the complaining party directly to resolve your issue.” However, there is a link allowing the recipient to appeal the takedown, which then leaves it up to Instagram moderators’ discretion if it returns.

Gagliano explained that this is a crucial area where trademark differs from copyright law. Thanks to the Digital Millenium Copyright Act (DMCA), there’s a clear (though often arduous) path to contesting false claims of copyright violations which allows content creators to get their posts put back. There’s no similar, mandatory pathway written into trademark law. “There's no counter notice process where they say, ‘Okay, you told us this is fair use, so we'll put it back up.’ And that's a really frustrating thing,” Gagliano said.

Mathew Zuniga, who does most of the booking for Tiny Sounds Collective, an organization that throws free DIY music shows and publishes zines, said he struggled with the process offered by Instagram after a post about a Tiny Sounds’ Smash By concert was taken down.

“I tried to do it,” he said. “It didn't really go through.“

When he reposted the same image and text, but without tagging Smash By Smash West’s Instagram account as a collaborator, the post remained online.

“I think it’s silly, as if these DIY shows in a bookstore are pulling anyone away from South By,” Zuniga said. “I think it was more of a deliberate attempt to take down anti-South By Southwest rhetoric online.”

When reached for comment, SXSW’s PR team sent back a prepared statement, noting that the law requires them to “take reasonable steps” to enforce their trademarks.

“SXSW’s efforts are not intended to limit commentary, criticism, or independent reporting, and we respect the importance of free expression,” the spokesperson’s statement continued. “We use third-party services, including BrandShield, to help identify potential issues at scale, and we recognize that errors can occur."

By contrast, Burnice explained that, rather than trying to steal SXSW’s trademark, Smash By Smash West makes it a condition that participants can’t describe their events as free or alternative SXSW events. “Smash By ... was an attempt to politicize the DIY scene, the ‘unofficial’ South By shows, and make them explicitly anti-South By.”

Smash By provides alternative logos, some of which are wholly unique but others based on parodying or “detournements” of the SXSW logo, similar to what the Austin for Palestine coalition did in 2024. Burnice expressed their frustration with the automated nature of the quashing of dissent this year.

“All of that is actually just happening by robots talking to robots,” they said. “It's an AI system that mass reports these accounts, and then, you know, probably an AI system at Instagram that just sorts through, and approves or rejects.”

For her part, Gagliano expressed skepticism over whether artificial intelligence plays a major or important role at companies like BrandShield beyond just its current popularity as a tech buzzword. ”I haven't seen any kind of change in the volume of requests for help that we're getting, and this is one thing where I'm a little skeptical that it's really made much difference, because they were already using automated tools before, and I think in any instance, the tools are not going to be able to reliably determine what's actually infringement.”


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.

GLITTER CARP e SEQUIN CARP: la Cina spia giornalisti e attivisti con phishing mirato e OAuth abuse
#CyberSecurity
insicurezzadigitale.com/glitte…


GLITTER CARP e SEQUIN CARP: la Cina spia giornalisti e attivisti con phishing mirato e OAuth abuse


Si parla di:
Toggle

Il Citizen Lab dell’Università di Toronto ha pubblicato un rapporto dettagliato che svela due distinti gruppi di hacker allineati con la Repubblica Popolare Cinese — denominati GLITTER CARP e SEQUIN CARP — responsabili di una campagna sistematica di sorveglianza digitale e phishing contro giornalisti investigativi, attivisti uiguri, tibetani, taiwanesi e hongkonghesi. La ricerca, condotta in collaborazione con l’International Consortium of Investigative Journalists (ICIJ), rappresenta un’ulteriore conferma della pervasività della repressione digitale transnazionale (DTR) orchestrata da Pechino.

Il contesto: la repressione digitale transnazionale della Cina


La Cina ha una lunga storia di persecuzione dei propri oppositori all’estero. Dagli anni ’90, le autorità di Pechino hanno minacciato, intimidito e fisicamente attaccato cittadini cinesi residenti all’estero che esprimevano dissenso verso il Partito Comunista. Nel corso dei decenni, la platea dei bersagli si è ampliata per includere esponenti delle diaspore tibetana, uigura, taiwanese e hongkonghese — i cosiddetti “Cinque Veleni” secondo la terminologia del CCP — oltre ai praticanti del Falun Gong e ai giornalisti che ne documentano le attività.

Il rapporto del Citizen Lab (Report No. 193, pubblicato il 27 aprile 2026) analizza come questa repressione si sia evoluta verso un modello di Military-Civil Fusion: attacchi state-sponsored eseguiti da contractor civili privati, con una netta divisione del lavoro tra i vari gruppi coinvolti. GLITTER CARP e SEQUIN CARP rappresentano due nodi distinti di questa rete, con TTP differenti ma finalità complementari.

GLITTER CARP: phishing massivo e furto di credenziali email


GLITTER CARP è attivo almeno dall’aprile 2025 e conduce una campagna di phishing ad ampio spettro, ma chirurgicamente mirata in termini di selezione delle vittime. Il gruppo ha colpito il World Uyghur Congress, lo Uyghur Human Rights Project (UHRP), TibCERT (la rete di risposta agli incidenti per la comunità tibetana), il media taiwanese Watchout e numerosi attivisti individuali come Carmen Lau, figura di spicco dell’attivismo hongkonghese.

Le tecniche adottate rivelano un’accurata preparazione operativa. In un caso emblematico, l’attivista uiguro-canadese Mehmet Tohti ha ricevuto un messaggio apparentemente proveniente da un noto regista uiguro, con una richiesta di visionare un documentario in anteprima. Il link non conduceva ad alcun video, ma a una pagina di login Google contraffatta. Il Citizen Lab ha inoltre identificato l’uso sistematico di tracking pixel nascosti nelle email di phishing, per verificare che il messaggio venisse aperto prima di procedere con la fase successiva dell’attacco.

L’infrastruttura di GLITTER CARP è stata documentata anche da Proofpoint, che ha osservato il riuso degli stessi domini e delle stesse identità impersonate in attacchi contro molteplici target. Il Citizen Lab ha identificato oltre cento domini correlati, alcuni dei quali probabilmente impiegati in operazioni non ancora rese pubbliche. L’obiettivo primario del gruppo sembra essere l’accesso iniziale ad account email, suggerendo un contratto specializzato all’interno del sistema Military-Civil Fusion che delega la compromissione dei dispositivi ad altri attori.

SEQUIN CARP: OAuth abuse e spionaggio dei giornalisti ICIJ


SEQUIN CARP opera con metodologie più sofisticate e ha come bersaglio principale i giornalisti dell’ICIJ impegnati nell’indagine “China Targets” — un progetto che documenta le pratiche di repressione transnazionale del CCP. La giornalista Scilla Alecci, coordinatrice del progetto, è stata oggetto di almeno tre tentativi di compromissione tra giugno 2025 e marzo 2026.

Il vettore d’attacco distintivo di SEQUIN CARP è il phishing OAuth: anziché rubare password, il gruppo induce le vittime a concedere autorizzazioni di accesso a email e calendario a un’applicazione di terze parti apparentemente legittima. Questa tecnica è particolarmente insidiosa perché:

  • Non richiede la conoscenza della password della vittima
  • Il token OAuth mantiene l’accesso anche dopo un cambio di password
  • L’accesso persiste finché la vittima non revoca manualmente il permesso dall’elenco delle app autorizzate
  • Le attività di lettura delle email non lasciano tracce nei log di accesso tradizionali

Per rendere credibili i propri approcci, SEQUIN CARP costruisce personas elaborate basate su narrative reali. In un caso, gli attaccanti hanno impersonato Bai Bin, un ex funzionario di un tribunale di Pechino la cui storia era già stata riportata da media cinesi, usando la sua identità per avvicinare la giornalista Alecci con una richiesta di informazioni apparentemente plausibile. Nonostante le capacità tecniche avanzate, il gruppo ha commesso errori operativi significativi che hanno permesso al Citizen Lab di tracciarne l’infrastruttura.

Attribuzione e implicazioni geopolitiche


Il Citizen Lab valuta con alta confidenza che entrambi i gruppi operino in favore della Repubblica Popolare Cinese, inserendosi nel pattern più ampio di repressione digitale transnazionale documentato negli ultimi anni. La coesistenza di due attori distinti con TTP differenti ma target sovrapposti suggerisce un ecosistema di contractor specializzati che risponde a mandati governativi specifici — un modello coerente con il sistema Military-Civil Fusion del governo cinese.

Proofpoint aveva già documentato attività correlate a GLITTER CARP contro altri soggetti legati agli interessi di Pechino, rafforzando l’ipotesi di una campagna coordinata e continuativa piuttosto che di operazioni episodiche. La duplice attenzione sull’ICIJ — con due attori separati che perseguono strategie diverse — evidenzia quanto l’organizzazione e i suoi giornalisti siano percepiti come minacce significative dalla leadership cinese.

Indicatori di Compromissione (IoC)

# Infrastruttura GLITTER CARP (domini impersonation identificati dal Citizen Lab)
# Categorie principali di impersonation:
# - Servizi Google (login, accounts, security-alerts)
# - Pagine ICIJ false
# - Profili di attivisti noti impersonati

# Tattiche SEQUIN CARP - OAuth Abuse
# Endpoint di autorizzazione OAuth abusati per accesso persistente a Gmail
# Tipologia di permessi richiesti: mail.read, calendar.readonly
# Vettore: email di spear-phishing con link a pagina di consent OAuth fake

# Tracking pixel:
# - Pixel nascosti nelle email per confermare apertura messaggio
# - Utilizzati come trigger per avanzamento attacco

# Referenza report completo:
# https://citizenlab.ca/research/how-chinese-actors-use-impersonation-and-stolen-narratives-to-perpetuate-digital-transnational-repression/

Come proteggersi: raccomandazioni per i difensori


Il Citizen Lab fornisce indicazioni pratiche per chi opera in ambienti ad alto rischio. In primo luogo, è fondamentale effettuare revisioni periodiche delle applicazioni OAuth autorizzate nel proprio account Google o Microsoft, revocando immediatamente qualsiasi accesso non riconosciuto o non più necessario. L’uso di chiavi di sicurezza hardware (FIDO2/WebAuthn) come secondo fattore di autenticazione rappresenta la misura più efficace contro i tentativi di phishing tradizionali, poiché il token fisico non può essere replicato su siti contraffatti.

Per i giornalisti e gli attivisti ad alto rischio, il Citizen Lab raccomanda l’adozione di strumenti come Access Now’s Digital Security Helpline e una formazione specifica sui pattern di spear-phishing legati alla repressione cinese. La verifica dell’identità dei contatti attraverso canali alternativi prima di cliccare su qualsiasi link — anche apparentemente proveniente da persone conosciute — rimane la misura preventiva più critica in questo contesto operativo.

Fonte primaria: Citizen Lab Report No. 193, “Tall Tales: How Chinese Actors Use Impersonation and Stolen Narratives to Perpetuate Digital Transnational Repression”, 27 aprile 2026. In collaborazione con ICIJ.


Building an x86 Gaming PC Without Intel, NVIDIA or AMD parts


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

This is an interesting challenge from the “why not?” files — [GPUSpecs] over on YouTube built a gaming PC without using a single component from NVIDIA, Intel, or AMD. That immediately makes us think of the high-power ARM workstations or perhaps even perhaps the new “AI workstations” coming available with RISC V architecture, but the challenge here was specifically “gaming PC,” not workstation. A gaming PC, without a GPU by one of those three? To make it even more interesting, the x86 CPU isn’t Intel or AMD either.

If you’re of a certain vintage, you may remember Cyrix. Cyrix reverse-engineered the x86 ISA and made their own compatible chips in the 90s, before being bought out by National Semiconductor, and then VIA Technologies. VIA partnered with the Government of Shanghai to found Zhaoxin, and it is from Zhaoxin that the KaiXian KX 7000 CPU hails — an x86-64 device, that isn’t Intel or AMD. We’ve actually covered the company before. This particular chip benchmarks like an old i5, so not spectacular, but usable.

The GPU is also Chinese: a Moore Threads MTT S80, with 16 GB of DDR6 vRAM, 4096 shading units, 256 texture mapping units, and 256 ROPs. On paper, that looks like a very respectable graphics card, but it’s not clear how well the games [GPUSpecs] tested were actually using it. Based on the numbers he was getting in his testing, there are some serious driver issues with this card. Even Black Myth: Wukong, which is supposed to be a game the card targets, was sitting at 13.6 FPS on low settings and 1080p. That almost feels like integrated graphics numbers, not something a beefy GPU would give you — but it matches what other reviewers were saying when the card first came out.

So if you’re looking for a sanction-proof gaming rig, we’re sorry to say it’s not quite ready for triple-A. On the other hand, it’s a neat hack and we didn’t know this box could even get built. Right now, it looks like you will need at least one of the big three names to game on–you can game on ARM with NVIDIA graphics, or even with Intel graphics, and of course AMD, which has been in the works the longest.

youtube.com/embed/rmxIjPCAp6w?…


hackaday.com/2026/04/30/buildi…

Cybersecurity & cyberwarfare ha ricondiviso questo.

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

Cybercrime S.p.A.: 455 dipendenti, 50 milioni di fatturato e il blitz dell’Europol

📌 Link all'articolo : redhotcyber.com/post/cybercrim…

A cura di Massimiliano Brolli

#redhotcyber #news #truffeonline #cybersecurity #europol #eurojust #truffeinitalia #callcenter

Cybersecurity & cyberwarfare ha ricondiviso questo.

Riflessione su Bluesky


Non mi piacciono:

  • i social commerciali;
  • i social centralizzati;
  • i social che danno spazio (per di più avallandole con pratiche di ufficializzazione) a strutture antidemocratiche e violente.

Perciò:

  • non intendo creare alcun account Bluesky;
  • non intendo pubblicare nulla in Bluesky neanche utilizzando il bridge.

Tuttavia non mi piace isolarmi completamente, perciò a malincuore e in modo limitato seguirò qualche account che da Bluesky pubblica nel Fediverso attraverso il bridge ed eventualmente boosterò qualche suo toot.

D'altronde mi sto già comportando così riguardo agli account #Threads.

#Bluesky

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

Large-scale #Roblox hacking operation shut down by Ukrainian authorities
securityaffairs.com/191500/cyb…
#securityaffairs #hacking