[Leo Goldstien] recently got in touch to let us know about a fascinating update he posted on the Hackaday.io page for ManiPylator — his 3D printed Six degrees of freedom, or 6DOF robotic arm.

This latest installment gives us a glimpse at what’s involved for command and control of such a device, as what goes into simulation and testing. Much of the requisite mathematics is introduced, along with a long list of links to further reading. The whole solution is based entirely on free and open source (FOSS) software, in fact a giant stack of such software including planning and simulation software on top of glue like MQTT message queues.

The practical exercise for this installment was to have the arm trace out the shape of a heart, given as a mathematical equation expressed in Python code, and it fared quite well. Measurements were taken! Science was done!

We last brought you word about this project in October of 2024. Since then, the project name has changed from “ManiPilator” to “ManiPylator”. Originally the name was a reference to the Raspberry Pi, but now the focus is on the Python programming language. But all the bot’s best friends just call him “Manny”.

If you want to get started with your own 6DOF robotic arm, [Leo] has traced out a path for you to follow. We’d love to hear about what you come up with!

youtube.com/embed/as9t7umI3mM?…

hackaday.com/2025/06/03/simula…

Federal agencies are transforming into the speech police under President Donald Trump. So why are some Democrats supporting the Kids Online Safety Act, a recently reintroduced bill that would authorize the MAGA-controlled Federal Trade Commission to enforce censorship?

As Freedom of the Press Foundation (FPF) senior advocacy adviser Caitlin Vogus wrote for The Boston Globe, there’s never an excuse for supporting censorship bills, but especially when political loyalists are at the FTC sure to abuse any power they’re given to stifle news on disfavored topics.

Vogus wrote, “KOSA’s supporters argue that it’s about keeping children under 17 safe from the harms of social media. But at the heart of the bill is something everyone should oppose: empowering the government to decide what speech children should be forbidden from seeing online.”

Read the article here.

freedom.press/issues/dont-empo…

Adding textures is a great way to experiment with giving 3D prints a different look, and [PandaN] shows off a method of adding a wood grain effect in a way that’s easy to play around with. It involves using a 3D model of a log (complete with concentric tree rings) as a print modifier. The good news is that [PandaN] has already done the work of creating one, as well as showing how to use it.
The model of the stump — complete with concentric tree rings — acts as a modifier for the much-smaller printed object (in this case, a small plate).
In the slicer software one simply uses the log as a modifier for an object to be printed. When a 3D model is used as a modifier in this way, it means different print settings get applied everywhere the object to be printed and the modifier intersect one another.

In the case of this project, the modifier shifts the angle of the fill pattern wherever the models intersect. A fuzzy skin modifier is used as well, and the result is enough to give a wood grain appearance to the printed object. When printed with a wood filament (which is PLA mixed with wood particles), the result looks especially good.

We’ve seen a few different ways to add textures to 3D prints, including using Blender to modify model surfaces. Textures can enhance the look of a model, and are also a good way to hide layer lines.

In addition to the 3D models, [PandaN] provides a ready-to-go project for Bambu slicer with all the necessary settings already configured, so experimenting can be as simple as swapping the object to be printed with a new 3D model. Want to see that in action? Here’s a separate video demonstrating exactly that step-by-step, embedded below.

youtube.com/embed/dPqu9Sk01jc?…

hackaday.com/2025/06/03/add-wo…

L’Obsolescenza tecnologia è una brutta bestia!

Ti ritrovi con dispositivi e applicazioni perfettamente funzionanti, ma ormai inutilizzabili perché i sistemi non sono più supportati, le app smettono di aggiornarsi e le patch di sicurezza diventano un miraggio. Non si tratta solo di un fastidio pratico: è anche un rischio concreto, soprattutto in ambito informatico. Tecnologie obsolete diventano il bersaglio preferito dei cyber attacchi, rendendo aziende, enti pubblici e utenti finali estremamente vulnerabili. Restare aggiornati non è più un’opzione: è una necessità.

Certo, non è affatto semplice affrontare un replatforming, cioè la migrazione di applicazioni e sistemi verso nuove piattaforme quando cambiano le major release dei prodotti. Questo processo può richiedere risorse, competenze e tempo. Tuttavia, prevedere questi ammodernamenti nel ciclo di vita del software è una responsabilità imprescindibile. Ignorarli significa accumulare debito tecnologico e mettere a rischio l’intero ecosistema digitale su cui si basa l’organizzazione.

Il Portale Accesso Sicuro della Regione Toscana

Il sito accessosicuro.rete.toscana.it/… è il portale ufficiale della Regione Toscana per l’accesso ai servizi online ad autenticazione sicura. Attraverso questo portale, cittadini, professionisti e operatori possono svolgere varie pratiche amministrative e sanitarie da remoto, in modo protetto e conforme alle normative vigenti.

A parte dei Directory Listing presenti all’interno del sito, la cosa che ci è stata portata all’attenzione da N3m0D4m è la versione del server Apache Tomcat presente in esercizio. Si parla della versione 6.0.33 che è andata in de supporto il 31 dicembre 2016.

Quindi stiamo parlando di un server che non riceve più patch di sicurezza da ben 9 anni.
Pagina di errore sul portale rete.toscana.it che mostra la presenza di un application server obsoleto

Cos’è l’obsolescenza tecnologica

L’obsolescenza tecnologica si verifica quando un sistema, un dispositivo o un software diventa inadeguato non perché smetta di funzionare, ma perché non riceve più supporto tecnico o aggiornamenti di sicurezza da parte del produttore.

Nel contesto della sicurezza informatica, questo è un problema altamente critico. Quando un sistema non viene più aggiornato, le vulnerabilità scoperte nel tempo restano aperte. Ogni bug o falla non corretta rappresenta una porta lasciata socchiusa che un attaccante può facilmente sfruttare. E quando si tratta di una applicazione esposta su internet, i rischi diventano molto ma molto più importanti.

Cosa succede esattamente?

• Nessuna patch di sicurezza: i cyber criminali cercano attivamente sistemi non aggiornati, perché sanno esattamente come colpirli.
• Espansione del rischio nel tempo: più tempo passa dall’ultimo aggiornamento, maggiore sarà il numero di vulnerabilità pubblicamente note che colpiscono quel sistema.
• Incompatibilità con nuove tecnologie di difesa: software EDR/XDR, antivirus, firewall o sistemi di monitoraggio moderni non sempre funzionano su tecnologie obsolete, lasciando interi ambienti scoperti.
• Utilizzo in attacchi a catena: un sistema vulnerabile può essere il punto d’ingresso per compromettere tutta una rete aziendale o istituzionale, anche se il server non eroga alcun servizio.

Un problema per tutti

Questo non è un rischio teorico: le cronache sono piene di casi in cui un semplice componente obsoleto ha permesso a un attaccante di prendere il controllo di interi sistemi. Nella pubblica amministrazione, dove spesso convivono tecnologie datate e dati sensibili, l’obsolescenza è una vera e propria bomba a orologeria.

E non si tratta solo di malware o ransomware: le falle non corrette possono permettere furti di dati personali, accessi non autorizzati, modifiche ai contenuti e molto altro.

Come affrontare l’obsolescenza tecnologica

Affrontare l’obsolescenza tecnologica richiede una visione strategica e un approccio proattivo.

Non basta reagire quando un sistema smette di funzionare o non riceve più aggiornamenti: è fondamentale pianificare in anticipo il ciclo di vita delle tecnologie utilizzate. Questo significa monitorare le date di fine supporto (EoL – End of Life) dei software e dei sistemi critici, stabilire una roadmap per gli aggiornamenti e prevedere risorse per interventi di manutenzione evolutiva. Ogni organizzazione dovrebbe adottare un inventario IT aggiornato, con indicatori chiari sullo stato e sulla criticità dei vari componenti, per prevenire l’accumulo di debito tecnologico.

La chiave è l’ammodernamento continuo, non l’intervento d’emergenza.

Quando possibile, è utile adottare soluzioni modulari e scalabili, che facilitino futuri aggiornamenti senza dover ricostruire da zero l’intera infrastruttura. Inoltre, il replatforming – per quanto complesso – deve essere considerato parte integrante della manutenzione a lungo termine. È importante coinvolgere team tecnici, responsabili della sicurezza e decisori strategici in un dialogo costante per valutare impatti, costi e benefici. Solo così è possibile garantire continuità operativa, sicurezza e sostenibilità nel tempo.

Concludendo

L’obsolescenza tecnologica non è solo una questione di efficienza o modernizzazione: è una questione di sicurezza. Continuare a utilizzare software o infrastrutture non più supportate equivale, nel mondo digitale, a lasciare la porta di casa aperta in un quartiere ad alto rischio.

Nel contesto attuale, dove gli attacchi informatici crescono in complessità e frequenza, ignorare gli aggiornamenti significa esporsi volontariamente al pericolo. E il prezzo da pagare non è solo tecnico: può tradursi in danni reputazionali, sanzioni per mancato rispetto delle normative (come il GDPR), perdita di dati sensibili e costi di ripristino elevati.

Aggiornare non è più una scelta, è un dovere di responsabilità digitale — sia per i privati, sia (e soprattutto) per le istituzioni pubbliche che gestiscono servizi essenziali per i cittadini.

La tecnologia evolve, ma la sicurezza non può restare indietro.

Come nostra consuetudine, lasciamo sempre spazio ad una dichiarazione dell’organizzazione qualora voglia darci degli aggiornamenti su questa vicenda e saremo lieti di pubblicarla con uno specifico articolo dando risalto alla questione.

RHC monitorerà l’evoluzione della vicenda in modo da pubblicare ulteriori news sul blog, qualora ci fossero novità sostanziali. Qualora ci siano persone informate sui fatti che volessero fornire informazioni in modo anonimo possono accedere utilizzare la mail crittografata del whistleblower.

L'articolo Obsolescenza Tecnologica. Accesso Sicuro della Regione Toscana su server obsoleto da 9 anni proviene da il blog della sicurezza informatica.

Growing up as a kid in the 1990s was an almost magical time. We had the best game consoles, increasingly faster computers at a pace not seen before, the rise of the Internet and World Wide Web, as well the best fashion and styles possible between neon and pastel colors, translucent plastic and also this little thing called Windows 95 that’d take the world by storm.

Yet as great as Windows 95 and its successor Windows 98 were, you had to be one of the lucky folks who ended up with a stable Windows 9x installation. The prebuilt (Daewoo) Intel Celeron 400 rig with 64 MB SDRAM that I had splurged on with money earned from summer jobs was not one of those lucky systems, resulting in regular Windows reinstalls.

As a relatively nerdy individual, I was aware of this little community-built operating system called ‘Linux’, with the online forums and the Dutch PC magazine that I read convincing me that it would be a superior alternative to this unstable ‘M$’ Windows 98 SE mess that I was dealing with. Thus it was in the Year of the Linux Desktop (1999) that I went into a computer store and bought a boxed disc set of SuSE 6.3 with included manual.

Fast-forward to 2025, and Windows is installed on all my primary desktop systems, raising the question of what went wrong in ’99. Wasn’t Linux the future of desktop operating systems?

Focus Groups

Boxed SuSE Linux 6.3 software. (Source: Archive.org)
Generally when companies gear up to produce something new, they will determine and investigate the target market, to make sure that the product is well-received. This way, when the customer purchases the item, it should meet their expectations and be easy to use for them.

This is where SuSE Linux 6.3 was an interesting experience for me. I’d definitely have classified myself in 1999 as your typical computer nerd who was all about the Pentiums and the MHz, so at the very least I should have had some overlap with the nerds who wrote this Linux OS thing.

The comforting marketing blurbs on the box promised an easy installation, bundled applications for everything, while suggesting that office and home users alike would be more than happy to use this operating system. Despite the warnings and notes in the installation section of the included manual, installation was fairly painless, with YAST (Yet Another Setup Tool) handling a lot of the tedium.

However, after logging into the new operating system and prodding and poking at it a bit over the course of a few days, reality began to set in. There was the rather rough-looking graphical interface, with what I am pretty sure was the FVWM window manager for XFree86, no font aliasing and very crude widgets. I would try the IceWM window manager and a few others as well, but to say that I felt disappointed was an understatement. Although it generally worked, the whole experience felt unfinished and much closer to using CDE on Solaris than the relatively Windows 98 or the BeOS Personal Edition 5 that I would be playing with around that time as well.

That’s when a friend of my older brother slipped me a completely legit copy of Windows 2000 plus license key. To my pleasant surprise, Windows 2000 ran smoothly, worked great and was stable as a rock even on my old Celeron 400 rig that Windows 98 SE had struggled with. I had found my new forever home, or so I thought.

Focus Shift

Start-up screen of FreeSCO. (Credit: Lewis “Lightning” Baughman, Wikimedia)
With Windows 2000, and later XP, being my primary desktop systems, my focus with Linux would shift away from the desktop experience and more towards other applications, such as the FreeSCO (en français) single-floppy router project, and the similar Smoothwall project. After upgrading to a self-built AMD Duron 600 rig, I’d use the Celeron 400 system to install various Linux distributions on, to keep tinkering with them. This led me down the path of trying out Wine to try out Windows applications on Linux in the 2000s, along with some Windows games ported by Loki Entertainment, with mostly disappointing results. This also got me to compile kernel modules, to make the onboard sound work in Linux.

Over the subsequent years, my hobbies and professional career would take me down into the bowels of Linux and similar with mostly embedded (Yocto) development, so that by now I’m more familiar with Linux from the perspective of the command line and architectural level. Although I have many Linux installations kicking around with a perfectly fine X/Wayland installation on both real hardware and in virtual machines, generally the first thing I do after logging in is pop open a Bash terminal or two or switching to a different TTY.

Yet now that the rainbows-and-sunshine era of Windows 2000 through Windows 7 has come to a fiery end amidst the dystopian landscape of Windows 10 and with Windows 11 looming over the horizon, it’s time to ask whether I would make the jump to the Linux desktop now.

Linux Non-Standard Base

Bringing things back to the ‘focus group’ aspect, perhaps one of the most off-putting elements of the Linux ecosystem is the completely bewildering explosion of distributions, desktop environments, window managers, package managers and ways of handling even basic tasks. All the skills that you learned while using Arch Linux or SuSE/Red Hat can be mostly tossed out the moment you are on a Debian system, never mind something like Alpine Linux. The differences can be as profound as when using Haiku, for instance.

Rather than Linux distributions focusing on a specific group of users, they seem to be primarily about doing what the people in charge want. This is illustrated by the demise of the Linux Standard Base (LSB) project, which was set up in 2001 by large Linux distributions in order to standardize various fundamentals between these distributions. The goals included a standard filesystem hierarchy, the use of the RPM package format and binary compatibility between distributions to help third-party developers.

By 2015 the project was effectively abandoned, and since then distributing software across Linux distributions has become if possible even more convoluted, with controversial ‘solutions’ like Canonical’s Snap, Flatpak, AppImage, Nix and others cluttering the landscape and sending developers scurrying back in a panic to compiling from source like it’s the 90s all over again.

Within an embedded development context this lack of standardization is also very noticeable, between differences in default compiler search paths, broken backwards compatibility — like the removal of ifconfig — and a host of minor and larger frustrations even before hitting big ticket items like service management flittering between SysV, Upstart, Systemd or having invented their own, even if possibly superior, alternatives like OpenRC in Alpine Linux.

Of note here is also that these system service managers generally do not work well with GUI-based applications, as CLI Linux and GUI Linux are still effectively two entirely different universes.

Wrong Security Model

For some inconceivable reason, Linux – despite not having UNIX roots like BSD – has opted to adopt the UNIX filesystem hierarchy and security model. While this is of no concern when you look at Linux as a wannabe-UNIX that will happily do the same multi-user server tasks, it’s an absolutely awful choice for a desktop OS. Without knowledge of the permission levels on folders, basic things like SSH keys will not work, and accessing network interfaces with Wireshark requires root-level access and some parts of the filesystem, like devices, require the user to be in a specific group.

When the expectation of a user is that the OS behaves pretty much like Windows, then the continued fight against an overly restrictive security model is just one more item that is not necessarily a deal breaker, but definitely grates every time that you run into it. Having the user experience streamlined into a desktop-friendly experience would help a lot here.

Unstable Interfaces

Another really annoying thing with Linux is that there is no stable kernel driver API. This means that with every update to the kernel, each of the kernel drivers have to be recompiled to work. This tripped me up in the past with Realtek chipset drivers for WiFi and Bluetooth. Since these were too new to be included in the Realtek driver package, I had to find an online source version on GitHub, run through the whole string of commands to compile the kernel driver and finally load it.

After running a system update a few days later and doing a restart, the system was no longer to be found on the LAN. This was because the WiFi driver could no longer be loaded, so I had to plug in Ethernet to regain remote access. With this experience in mind I switched to using Wireless-N WiFi dongles, as these are directly supported.

Experiences like this fortunately happen on non-primary systems, where a momentary glitch is of no real concern, especially since I made backups of configurations and such.

Convoluted Mess

This, in a nutshell, is why moving to Linux is something that I’m not seriously considering. Although I would be perfectly capable of using Linux as my desktop OS, I’m much happier on Windows — if you ignore Windows 11. I’d feel more at home on FreeBSD as well as it is a far more coherent experience, not to mention BeOS’ successor Haiku which is becoming tantalizingly usable.

Secretly my favorite operating system to switch to after Windows 10 would be ReactOS, however. It would bring the best of Windows 2000 through Windows 7, be open-source like Linux, yet completely standardized and consistent, and come with all the creature comforts that one would expect from a desktop user experience.

One definitely can dream.

hackaday.com/2025/06/03/my-win…

The risks associated with containerized environments

Although containers provide an isolated runtime environment for applications, this isolation is often overestimated. While containers encapsulate dependencies and ensure consistency, the fact that they share the host system’s kernel introduces security risks.

Based on our experience providing Compromise Assessment, SOC Consulting, and Incident Response services to our customers, we have repeatedly seen issues related to a lack of container visibility. Many organizations focus on monitoring containerized environments for operational health rather than security threats. Some lack the expertise to properly configure logging, while others rely on technology stacks that don’t support effective visibility of running containers.

Environments that suffer from such visibility issues are often challenging for threat hunters and incident responders because it can be difficult to clearly distinguish between processes running inside a container and those executed on the host itself. This ambiguity makes it difficult to determine the true origin of an attack and whether it started in a compromised container or directly on the host.

The aim of this blog post is to explain how to restore the execution chain inside a running container using only host-based execution logs, helping threat hunters and incident responders determine the root cause of a compromise.

How containers are created and operate

To effectively investigate security incidents and hunt for threats in containerized environments, it’s essential to understand how containers are created and how they operate. Unlike virtual machines, which run as separate operating systems, containers are isolated user-space environments that share the host OS kernel. They rely on namespaces, control groups (cgroups), union filesystems, Linux capabilities, and other Linux features for resource management and isolation.

Because of this architecture, every process inside a container technically runs on the host, but within a separate namespace. Threat hunters and incident responders typically rely on host-based execution logs to gain a retrospective view of executed processes and command-line arguments. This allows them to analyze networks that lack dedicated containerization environment monitoring solutions. However, some logging configurations may lack critical attributes such as namespaces, cgroups, or specific syscalls. In such cases, rather than relying solely on missing log attributes, we can bridge this visibility gap by understanding the process execution chain of a running container from a host perspective.

Overview of the container creation workflow

End users interact with command-line utilities, such as Docker CLI, kubectl and others, to create and manage their containers. On the backend, these utilities communicate with an engine that facilitates communication with a high-level container runtime, most commonly containerd or CRI-O. These high-level container runtimes leverage low-level container runtimes like runc (the most common) to do the heavy lifting of interacting with the Linux OS kernel. This interaction allocates cgroups, namespaces, and other Linux capabilities for creating and killing containers based on a bundle provided by the high-level runtime. The high-level runtime is, in its turn, based on user-provided arguments. The bundle is a self-contained directory that defines the configuration of a container according to the Open Container Initiative (OCI) Runtime Specification. It mainly consists of:

1. A rootfs directory that serves as the root filesystem for the container. It is created by extracting and combining the layers from a container image, typically using a union filesystem like OverlayFS.
2. A config.json file describing an OCI runtime configuration that specifies the necessary process, mounts, and other configurations necessary for creating the container.

It’s important to note which mode runc has been executed in, since it supports two modes: foreground mode and detached mode. The resulting process tree may vary depending on the chosen mode. In foreground mode, a long-running runc process remains in the foreground as a parent process for the container process, primarily to handle the stdio so the end user can interact with the running container.

Process tree of a container created in foreground mode using runc

In detached mode, however, there will be no long-running runc process. After creating the container, runc exits, leaving the caller process to take care of the stdio. In most cases, this is containerd or CRI-O. As we can see in the screenshot below, when we execute a detached container using runc, the runc process will create it and immediately exit. Hence, the parent process of the container is the host’s PID 1 (systemd process).

Process tree of a container created in detached mode using runc

However, if we create a detached container using Docker CLI, for example, we’ll notice that the parent of the container process is a shim process, not PID 1!

Process tree of a container created in detached mode using Docker CLI

In modern architectures, communication between high- and low-level container runtimes is proxied through a shim process. This allows containers to run independently of the high-level container runtime, ensuring the sustainability of the running container even if the high-level container runtime crashes or restarts. The shim process also manages the stdio of the container process so users can later attach to running containers via commands like docker exec -it <container>, for example. The shim process can also redirect stdout and stderr to log files that users can later inspect either directly from the filesystem or via commands like kubectl logs <pod> -c <container>.

When a detached container is created using Docker CLI, the high-level container runtime, for example, containerd, executes a shim process that calls runc as a low-level container runtime for the sole purpose of creating the container in detached mode. After that, runc immediately exits. To avoid orphan processes or reparenting to the PID 1, as in the case when we executed runc ourselves, the shim process explicitly sets itself as a subreaper to adopt the container processes after runc exits. A Linux subreaper process is a designated parent that takes care of orphaned child processes in its chain (instead of init), allowing it to manage and clean up its entire process tree.

Detached containers will be reparented to the shim process after creation

This is implemented in the latest V2 shim and is the default in the modern containerd implementations.

The shim process sets itself as a subreaper process during creation

When we check the help message of the containerd-shim-runc-v2 process, for example, we notice that it accepts the container ID as a command-line argument, and calls it the id of the task.

Help message of the shim process

We can confirm this by checking the command-line arguments of the running containerd-shim-runc-v2 processes and comparing them with the running containers.

The shim process accepts the ID of the relevant container as a command-line argument

So far, we’ve successfully identified container processes from the host’s perspective. In modern architectures, one of the following processes will typically be seen as a predecessor process for the containerized processes:

• A shim process, in the case of detached mode; or
• A runc process, in the case of foreground (interactive) mode.

We can also use the command-line arguments of the shim process to determine which container the process belongs to.

Process tree of the containers from the host perspective

Although tracking the child processes of the shim process can sometimes lead to easy wins, it is often not as easy as it sounds, especially when there are a lot of subprocesses between the shim process and the malicious process. In this case, we can take a bottom-to-top approach, pivoting from the malicious process, tracking its parents all the way up to the shim process to confirm that it was executed inside a running container. It then becomes a matter of choosing the process whose behavior we may need to check for malicious or suspicious activities.

Since containers typically run with minimal dependencies, attackers often rely on shell access to either execute commands directly, or install missing dependencies for their malware. This makes container shells a critical focus for detection. But how exactly do these shells behave? Let’s take a closer look at one of the key shell processes in containerized environments.

How do BusyBox and Alpine execute commands?

In this post, we focus on the behavior of BusyBox-based containers. We also included Alpine-based containers as an example of an image base that relies on BusyBox to implement many core Linux utilities, helping to keep the image lightweight. For the sake of demonstration, Alpine images that depend on other utilities are outside the scope of this post.

BusyBox provides minimalist replacements for many commonly used UNIX utilities, combining them into one small executable. This allows for the creation of lightweight containers with significantly reduced image sizes. But how does the BusyBox executable actually work?

BusyBox has its own implementation of system utilities, known as applets. Each applet is written in C and stored in the busybox/coreutils/ directory as part of the source code. For example, the UNIX cat utility has a custom implementation named cat.c. At runtime, BusyBox creates an applet table that maps applet names to their corresponding functions. This table is used to determine which applet to execute based on the command-line argument provided. This mechanism is defined in the appletlib.c file.

Snippet of the appletlib.c file

When an executed command calls an installed utility that is not a default applet, BusyBox relies on the PATH environment variable to determine the utility’s location. Once the path is identified, BusyBox spawns the utility as a child process of the BusyBox process itself. This dynamic execution mechanism is critical to understanding how command execution works within a BusyBox-based container.

Applet/program execution logic

Now that we have a clear understanding of how the BusyBox binary operates, let’s explore how it functions when running inside a container. What happens, for example, when you execute the sh command inside such containers?

In both BusyBox and Alpine containers, executing the sh command to access the shell doesn’t actually invoke a standalone binary called sh. Instead, the BusyBox binary itself is executed. In BusyBox containers we can verify that /bin/sh is replaced by BusyBox by comparing the inodes of /bin/sh and /bin/busybox using ls -li and confirm that both have the same inode number. We can also print their MD5 hash to see that they are the same, and by executing /bin/sh --help, we’ll see that the banner of BusyBox is the one that’s printed.

/bin/sh is replaced by the /bin/busybox on the BusyBox based containers

On the other hand, in the Alpine containers, /bin/sh is a symbolic link to /bin/busybox. This means that when you run the sh command, it actually executes the BusyBox executable referred to by the symbolic link. This can be confirmed by executing readlink -f /bin/sh and observing the output.

/bin/sh is a symbolic link to /bin/busybox in the Alpine-based containers

Hence, inside BusyBox- or Alpine-based containers, all shell commands are either executed directly by the BusyBox process or are launched as child processes under the BusyBox process. These processes run within isolated namespaces on the host operating system, providing the necessary containerization while still utilizing the shared kernel of the host.

From a threat hunting perspective, having a non-standard shell process for the host OS, like BusyBox in this case, should prompt further investigation. Why would a BusyBox shell process be running on a Debian or a RedHat OS? Combining this conclusion with the previous one allows us to confirm that the shell was executed inside a container when runc or shim is observed as the predecessor process to the BusyBox process. This knowledge can be applied not only to the BusyBox process but also to any other process executed inside a running container. This knowledge is crucial for effectively determining the origin of suspicious behavior while hunting for threats using the host execution logs.

Some security tools, such as Kaspersky Container Security, are designed to monitor container activity and detect suspicious behavior. Others, such as Auditd, provide enriched logging at the kernel level based on preconfigured rules that capture system calls, file access, and user activity. However, these rules are often not optimized for containerized environments, further complicating the distinction between host and container activity.

Investigation value

While investigating execution logs, threat hunters and incident responders might overlook some activities on Linux machines, thinking they are part of normal operations. However, the same activities performed inside a running container should raise suspicion. For example, installing utilities such as Docker CLI may be normal on the host, but not inside a container. Recently, in a Compromise Assessment project, we discovered a crypto mining campaign in which the threat actor installed Docker CLI inside a running container in order to easily communicate with dockerd APIs.

Confirming that the docker.io installation occurred inside a running container

In this example, we detected the installation of Docker CLI inside a container by tracing the process chain. We then determined the origin of the executed command and confirmed the container in which the command was executed by checking the command-line argument of the shim process.

During another investigation, we detected an interesting event where the process name was systemd while the process executable path was /.redtail. To identify the origin of this process, we followed the same procedure of tracking the parent processes.

Determining the container in which the suspicious event occurred

Another interesting fact we can leverage is that a Docker container is always created by a runc process as the low-level container runtime. The runc help message reveals the command-line arguments used to create, run or start a container.

runc help messate

Monitoring these events helps threat hunters and incident responders identify the ID of the subject container and detect any abnormal entrypoints. A container’s entrypoint is its main process and it will be the process spawned by runc. The screenshot below shows an example of the creation of a malicious container detected by hunting for entrypoints with suspicious command-line arguments. In this case, the command line contains a malicious base64-encoded command.

Hunting for suspicious container entrypoints

Conclusion

Containerized environments are now part of most organizations’ networks because of the deployment and dependency encapsulation feasibility they provide. However, they are usually overlooked by security teams and decision makers because of a common misunderstanding about container isolation. This results in undesirable situations when these containers are compromised, and the security team is not fully equipped with the knowledge or tools to help during response activities, or even to monitor or detect in the first place.

The approach discussed in this post is one of the procedures that we typically follow in our Compromise Assessment and Incident Response services when we need to hunt for threats in historical host execution logs with container visibility issues. However, in order to detect container-based threats in time, it is crucial to protect your systems with a solid containerization monitoring solution, such as Kaspersky Container Security.

securelist.com/host-based-logs…

I file PDF sono fondamentali nella condivisione dei documenti digitali perché sono comodi e semplici da usare. Però, questa fiducia li ha resi anche un bersaglio facile per i cybercriminali. Secondo i dati recenti, i PDF costituiscono quasi il 30-40% dei file dannosi veicolati via email. Un semplice PDF può nascondere delle minacce sofisticate.

Nell’ambito della cybersecurity, è fondamentale capire come un file apparentemente innocuo possa diventare un’arma. Quali sono gli attacchi noti che hanno sfruttato questo formato? Quali sono le varianti di PDF che risultano più sicure? È buona norma utilizzare degli strumenti affidabili per la gestione dei PDF, come le piattaforme specifiche e sicure con la funzione unisci pdf per combinare i documenti. In questo modo, si riduce il rischio di manipolazioni malevole nelle operazioni più comuni.

In questo articolo, vediamo quali sono le principali tecniche di attacco tramite i PDF, analizziamo dei casi reali e spieghiamo come difendersi considerando i formati PDF più sicuri e le best practice.

Il PDF come vettore di attacco informatico

Il formato PDF è nato per garantire una rappresentazione fedele dei documenti su qualsiasi sistema. Col tempo si è arricchito di tante funzionalità avanzate: oggi un PDF può contenere dei moduli compilabili, degli elementi multimediali, degli oggetti 3D e persino degli script JavaScript. Questa versatilità ha un rovescio della medaglia: ciò che migliora l’esperienza utente può essere sfruttato dai malintenzionati. Un PDF manipolato può eseguire del codice arbitrario sul sistema della vittima sfruttando le vulnerabilità del software lettore. Già alla fine degli anni 2000 ci sono stati degli attacchi di questo tipo: ad esempio l’exploit CVE-2010-1240, diffuso via spam, consentiva di infettare il PC all’apertura del PDF installando un trojan botnet.

Un altro aspetto critico è la percezione di sicurezza che circonda i PDF. Molti utenti li considerano più sicuri di un file eseguibile o di un documento Office con macro, e i PDF spesso eludono anche i filtri antispam più basilari. I criminali sfruttano questa fiducia inviando PDF dall’aspetto legittimo (fatture, contratti, moduli) che in realtà celano dei contenuti pericolosi. Da notare che anche i browser web moderni includono dei visualizzatori PDF integrati: una falla in quei componenti potrebbe essere sfruttata inducendo la vittima a visualizzare un PDF malevolo online, senza nemmeno scaricarlo.

Tecniche di attacco tramite file PDF

Gli aggressori hanno sviluppato varie tecniche per compromettere i sistemi attraverso i file PDF. Di seguito alcune delle più comuni:

• Script malevoli integrati: Inserire del codice JavaScript in un PDF è uno dei metodi più diffusi. Lo script può essere offuscato nella struttura del documento e può essere programmato per attivarsi all’apertura. Ad esempio, l’exploit CVE-2018-4990 usava uno script e un oggetto immagine predisposto per corrompere la memoria di Adobe Reader ed eseguire codice maligno.
• Sfruttamento delle vulnerabilità: Molti attacchi PDF puntano sulle falle sconosciute o non ancora risolte nei lettori. Adobe, ad esempio, nel 2021 ha risolto un bug critico (CVE-2021-28550) già sfruttato in diversi attacchi mirati. In questi casi aprire il PDF è sufficiente a infettare il sistema, poiché il file sfrutta un bug del programma per eseguire del codice arbitrario.
• Phishing tramite PDF: Spesso il PDF funge da veicolo di inganni per l’utente. Un documento può imitare una pagina di login o una comunicazione ufficiale. In questo modo, inducendo la vittima a cliccare i link esterni o a inserire le credenziali. Ad esempio, un PDF può mostrare un finto pulsante “Accedi al documento” che apre un sito di phishing, oppure può includere un codice QR che conduce a una pagina web malevola. Il file supera i filtri email, ma può comunque portare l’utente a compiere delle azioni pericolose.

Casi reali di attacchi tramite PDF

Tra gli incidenti documentati più significativi ci sono questi:

• 2018: attacco mirato che combinava due exploit 0-day (Adobe Reader CVE-2018-4990 e Windows) per eseguire malware sul sistema bersaglio.
• 2021: vulnerabilità di Adobe Reader (CVE-2021-28550) sfruttata in attacchi reali prima dell’uscita della patch.
• 2024: campagna DarkGate in cui dei PDF con dei link offuscati reindirizzavano le vittime su dei siti compromessi. Sfruttavano una falla Windows (CVE-2024-21412) per aggirare SmartScreen e per installare un malware sui sistemi.
• 2025: PDF con falsi inviti DocuSign hanno innescato dei download di malware. Nello stesso periodo, dei PDF con dei codici QR hanno dirottato gli utenti verso delle false pagine di login Microsoft 365 per rubare le credenziali.

I formati PDF più sicuri e come difendersi

Esistono varianti e impostazioni del PDF che offrono più sicurezza. In ambito professionale si fa spesso riferimento al PDF/A, lo standard ISO pensato per l’archiviazione a lungo termine. Il PDF/A impone delle restrizioni rispetto al PDF standard: ad esempio, vieta i contenuti dinamici (video, audio, script) e privilegia la staticità del documento. Un file conforme a PDF/A non può contenere macro o codice eseguibile nascosto, quindi riduce il rischio di attacchi. Convertire un PDF in PDF/A (o generarlo direttamente così) è una buona pratica quando si condividono i documenti in contesti ad alto rischio. In questo modo, gli eventuali elementi pericolosi vengono eliminati.

Un ulteriore accorgimento è l’uso della firma digitale sui PDF. Un documento firmato digitalmente offre delle garanzie di integrità e di autenticità: qualunque modifica malevola del file ne invaliderebbe la firma e, quindi, segnalerebbe che il contenuto è stato alterato.

Infine, ecco alcune best practice per ridurre i rischi nell’uso dei PDF:

• Mantenere aggiornati i lettori: Installare sempre le ultime patch di sicurezza per Acrobat, Foxit e gli altri software PDF così da correggere al più presto le vulnerabilità note.
• Limitare le funzionalità attive: Disabilitare l’esecuzione di JavaScript e di altri contenuti attivi se non strettamente necessari. Questo riduce la possibilità che del codice indesiderato venga eseguito all’apertura dei documenti.
• Verificare l’origine dei PDF: Trattare con cautela gli allegati non attesi, soprattutto se provenienti da degli account sconosciuti. In ambito aziendale, conviene verificare per vie ufficiali la legittimità di un PDF prima di aprirlo.
• Usare ambienti isolati: Aprire eventuali PDF sospetti in una sandbox o tramite un visualizzatore online, in modo che il documento non interagisca con il sistema locale e, se è malevolo, i suoi effetti rimangano confinati.
• Sensibilizzare gli utenti: Formare il personale sul fatto che anche i PDF possono veicolare delle minacce, fornire delle indicazioni per riconoscere i comportamenti anomali e per segnalare le attività sospette.

Con le giuste precauzioni si può continuare a utilizzare i PDF minimizzando i rischi legati agli attacchi informatici.

L'articolo Attacchi informatici tramite PDF: Quali sono i formati più sicuri proviene da il blog della sicurezza informatica.

La repentina caduta del regime di Bashar al-Assad, culminata con la perdita di Damasco l’8 dicembre 2024 e l’ascesa Ahmed Husayn al-Sharaa, meglio noto come Abu Muhammad Al Jolani, leader del gruppo jihadista Hayat Tahrir al-Sham (Hts), rappresenta uno degli eventi più significativi della storia recente della Siria. Un’inchiesta condotta da Newlines Magazine getta luce su un aspetto meno visibile e conosciuto della fine di Assad: una sofisticata operazione di guerra cibernetica che ha sfruttato la vulnerabilità di un esercito già indebolito da anni di conflitto, crisi economica e morale. La narrazione tradizionale di una sconfitta militare dovuta a un attacco dell’opposizione a Aleppo non basta a spiegare l’improvvisa dissoluzione dell’esercito siriano. Dietro le quinte, infatti, un’applicazione mobile, apparentemente innocua, ha svolto un ruolo cruciale, trasformando gli smartphone degli ufficiali in strumenti di spionaggio.

La guerra cyber ha giocato un ruolo fondamentale

Secondo Newlines Magazine, un’applicazione chiamata STFD-686, distribuita tramite un canale Telegram sotto il nome di Syria Trust for Development (un’organizzazione umanitaria legata ad Asma al-Assad), si è rivelata una trappola. Promettendo aiuti economici, l’app chiedeva agli ufficiali di inserire dati personali e militari sensibili, come nome, grado, posizione e dettagli sulle unità di appartenenza. Questi dati, raccolti tramite un’interfaccia web che reindirizzava a siti fasulli come syr1.store e syr1.online, hanno permesso agli operatori dell’attacco di mappare in tempo reale le posizioni dell’esercito siriano, individuando punti deboli e depositi di armi. L’app installava inoltre SpyMax, un software di sorveglianza che consentiva di accedere a chiamate, messaggi, foto e persino alla videocamera dei dispositivi, trasformando i telefoni in strumenti di spionaggio remoto.

L’inchiesta evidenzia come questa operazione abbia sfruttato non solo la tecnologia, ma anche la disperazione degli ufficiali siriani. Con salari ridotti a circa 20 dollari al mese a causa del crollo della lira siriana (da 50 a 15.000 contro il dollaro tra il 2011 e il 2023), molti militari erano demoralizzati e inclini ad accettare qualsiasi promessa di aiuto finanziario. La mancata applicazione di protocolli di sicurezza, come dimostrato dall’episodio del 2020 in cui un telefono lasciato acceso in un veicolo Pantsir-S1 portò a un attacco aereo israeliano, ha amplificato le vulnerabilità. L’esercito siriano, già logorato da anni di guerra, corruzione e stagnazione politica, non ha mai intrapreso contromisure efficaci contro queste minacce cibernetiche.

L’impatto dell’attacco è stato devastante. La raccolta di dati sensibili ha permesso agli oppositori del regime di pianificare l’Operazione Deterrenza dell’Aggressione, iniziata a novembre 2024, che ha portato alla rapida conquista di Aleppo e, successivamente, di Damasco. L’inchiesta suggerisce che i dati raccolti abbiano facilitato attacchi mirati, come quello alla sala operativa militare di Aleppo, e creato confusione tra i comandi, come nel caso dello scontro tra le forze dei generali Saleh al-Abdullah e Suhail al-Hassan il 6 dicembre 2024. Non è chiaro chi abbia orchestrato l’attacco: potrebbe trattarsi di fazioni dell’opposizione, servizi segreti regionali o internazionali, o persino attori non ancora identificati. Tuttavia, l’efficacia dell’operazione evidenzia una nuova era di guerra ibrida, in cui la tecnologia si intreccia con le debolezze umane e istituzionali.

La fine delle sanzioni europee sulla Siria

In risposta alla caduta del regime di Assad, l’Unione Europea ha deciso di appoggiare politicamente la transizione del Paese e il governo di al-Sharaa. Il 20 maggio scorso, il Consiglio dell’Ue ha infatti avviato l’iter per la rimozione di tutte le sanzioni economiche contro la Siria, ad eccezione di quelle motivate da ragioni di sicurezza. Questa decisione, come dichiarato da Kaja Kallas, Alto Rappresentante per gli Affari Esteri, mira a “sostenere il popolo siriano nel riunirsi e ricostruire una Siria nuova, inclusiva, pluralistica e pacifica”.

Sono state rimosse dalle liste delle sanzioni 24 entità, tra cui la Banca Centrale di Siria e aziende operanti nei settori del petrolio, del cotone e delle telecomunicazioni. Tuttavia, l’Ue ha esteso fino al 1° giugno 2026 le sanzioni contro individui ed entità legate al regime di Assad e ha introdotto nuove misure restrittive contro due individui e tre entità responsabili di gravi violazioni dei diritti umani nella regione costiera siriana di marzo 2025: violenze che, come abbiamo raccontato su InsideOver, sono state commesse con il tacito assenso degli uomini di al-Jolani.

Il primo attacco dell’Isis al nuovo governo siriano

Parallelamente alla transizione politica, la Siria deve affrontare la minaccia dell’ISis, che ha rivendicato il suo primo attacco contro le forze del nuovo governo siriano dopo la caduta di Assad. Secondo Site Intelligence Group e l’Osservatorio Siriano per i Diritti Umani, l’attacco, avvenuto mercoledì 29 maggio nella provincia meridionale di Sweida, ha coinvolto un ordigno esplosivo telecomandato che ha colpito un veicolo della 70ª Divisione dell’esercito siriano, uccidendo una persona e ferendo tre soldati. Sebbene l’Isis sia stato territorialmente sconfitto in Siria nel 2019, il gruppo mantiene una presenza nel deserto e continua a colpire, soprattutto le forze curde nel nord-est.

Recentemente, le autorità siriane hanno arrestato membri di una cellula Isis vicino a Damasco, accusati di pianificare attacchi, mentre un’operazione ad Aleppo ha portato alla morte di un ufficiale e tre membri dello Stato Islamico. Durante un incontro a Riyadh, il presidente statunitense Donald Trump ha esortato il leader siriano ad interim, Ahmad al-Sharaa, a collaborare per prevenire la rinascita dell’Isis, sottolineando l’importanza di una vigilanza costante.

Noi di InsideOver ci mettiamo cuore, esperienza e curiosità per raccontare un mondo complesso e in continua evoluzione. Per farlo al meglio, però, abbiamo bisogno di te: dei tuoi suggerimenti, delle tue idee e del tuo supporto. Unisciti a noi, abbonati oggi!

L'articolo La Siria e la caduta di Assad: il ruolo cruciale e nascosto della guerra cyber proviene da InsideOver.

Gli hacker di NoName057(16) riavviano le loro attività ostili contro diversi obiettivi italiani, attraverso attacchi di Distributed Denial-of-Service (DDoS).

NoName057(16) è un gruppo di hacker che si è dichiarato a marzo del 2022 a supporto della Federazione Russa. Hanno rivendicato la responsabilità di attacchi informatici a paesi come l’Ucraina, gli Stati Uniti e altri vari paesi europei. Questi attacchi vengono in genere eseguiti su agenzie governative, media e siti Web di società private.

Nella giornata di oggi, vengono rivendicati attacchi DDoS contro le seguenti organizzazioni italiane:

• Operatore di telefonia mobile Digi Mobil check-host.net/check-report/2726d7efk24b
• Operatore di telefonia mobile Tiscali check-host.net/check-report/2726d6bck472
• Khoster Tiscali check-host.net/check-report/2726d6dck5a1
• Compagnia di telecomunicazioni Tessellis check-host.net/check-report/2726d727k64b
• Compagnia di telecomunicazioni Acantho check-host.net/check-report/2726d741k1da
• Corpo Parma (morto nel ping) check-host.net/check-report/2726da4fk7a0
• Hortic Revo-Nel-Emilia check-host.net/check-report/2726d9cakaf6
• Città Rimini check-host.net/check-report/2726da03k977

Telegram ha intensificato la sua azione contro i gruppi hacker filorussi come Noname057(16), noti per le loro campagne di attacchi DDoS contro obiettivi europei. La piattaforma sta infatti rimuovendo con sistematicità i canali Telegram utilizzati da questi attori per coordinare le operazioni, diffondere propaganda e rivendicare gli attacchi.

Questa strategia sta mettendo in difficoltà gruppi come Noname057(16), costretti a ricreare continuamente nuovi canali e a ricostruire da zero la propria base di follower, con un conseguente calo dell’influenza e della visibilità delle loro azioni. La lotta di Telegram rappresenta quindi un importante ostacolo alla continuità comunicativa e operativa di questi gruppi, contribuendo a limitarne l’impatto nell’ecosistema della minaccia cibernetica.

Che cos’è un attacco Distributed Denial of Service

Un attacco DDoS (Distributed Denial of Service) è un tipo di attacco informatico in cui vengono inviate una grande quantità di richieste a un server o a un sito web da molte macchine diverse contemporaneamente, al fine di sovraccaricare le risorse del server e renderlo inaccessibile ai suoi utenti legittimi.

Queste richieste possono essere inviate da un grande numero di dispositivi infetti da malware e controllati da un’organizzazione criminale, da una rete di computer compromessi chiamata botnet, o da altre fonti di traffico non legittime. L’obiettivo di un attacco DDoS è spesso quello di interrompere le attività online di un’organizzazione o di un’azienda, o di costringerla a pagare un riscatto per ripristinare l’accesso ai propri servizi online.

Gli attacchi DDoS possono causare danni significativi alle attività online di un’organizzazione, inclusi tempi di inattività prolungati, perdita di dati e danni reputazionali. Per proteggersi da questi attacchi, le organizzazioni possono adottare misure di sicurezza come la limitazione del traffico di rete proveniente da fonti sospette, l’utilizzo di servizi di protezione contro gli attacchi DDoS o la progettazione di sistemi resistenti agli attacchi DDoS.

Occorre precisare che gli attacchi di tipo DDoS, seppur provocano un disservizio temporaneo ai sistemi, non hanno impatti sulla Riservatezza e Integrità dei dati, ma solo sulla loro disponibilità. pertanto una volta concluso l’attacco DDoS, il sito riprende a funzionare esattamente come prima.

Che cos’è l’hacktivismo cibernetico

L’hacktivismo cibernetico è un movimento che si serve delle tecniche di hacking informatico per promuovere un messaggio politico o sociale. Gli hacktivisti usano le loro abilità informatiche per svolgere azioni online come l’accesso non autorizzato a siti web o a reti informatiche, la diffusione di informazioni riservate o il blocco dei servizi online di una determinata organizzazione.

L’obiettivo dell’hacktivismo cibernetico è di sensibilizzare l’opinione pubblica su questioni importanti come la libertà di espressione, la privacy, la libertà di accesso all’informazione o la lotta contro la censura online. Gli hacktivisti possono appartenere a gruppi organizzati o agire individualmente, ma in entrambi i casi utilizzano le loro competenze informatiche per creare un impatto sociale e politico.

È importante sottolineare che l’hacktivismo cibernetico non deve essere confuso con il cybercrime, ovvero la pratica di utilizzare le tecniche di hacking per scopi illeciti come il furto di dati personali o finanziari. Mentre il cybercrime è illegale, l’hacktivismo cibernetico può essere considerato legittimo se mira a portare all’attenzione pubblica questioni importanti e a favorire il dibattito democratico. Tuttavia, le azioni degli hacktivisti possono avere conseguenze legali e gli hacktivisti possono essere perseguiti per le loro azioni.

Chi sono gli hacktivisti di NoName057(16)

NoName057(16) è un gruppo di hacker che si è dichiarato a marzo del 2022 a supporto della Federazione Russa. Hanno rivendicato la responsabilità di attacchi informatici a paesi come l’Ucraina, gli Stati Uniti e altri vari paesi europei. Questi attacchi vengono in genere eseguiti su agenzie governative, media e siti Web di società private

Le informazioni sugli attacchi effettuati da NoName057(16) sono pubblicate nell’omonimo canale di messaggistica di Telegram. Secondo i media ucraini, il gruppo è anche coinvolto nell’invio di lettere di minaccia ai giornalisti ucraini. Gli hacker hanno guadagnato la loro popolarità durante una serie di massicci attacchi DDOS sui siti web lituani.

Le tecniche di attacco DDoS utilizzate dal gruppo sono miste, prediligendo la “Slow http attack”.

La tecnica del “Slow Http Attack”

L’attacco “Slow HTTP Attack” (l’articolo completo a questo link) è un tipo di attacco informatico che sfrutta una vulnerabilità dei server web. In questo tipo di attacco, l’attaccante invia molte richieste HTTP incomplete al server bersaglio, con lo scopo di tenere occupate le connessioni al server per un periodo prolungato e impedire l’accesso ai legittimi utenti del sito.

Nello specifico, l’attacco Slow HTTP sfrutta la modalità di funzionamento del protocollo HTTP, che prevede che una richiesta HTTP sia composta da tre parti: la richiesta, la risposta e il corpo del messaggio. L’attaccante invia molte richieste HTTP incomplete, in cui il corpo del messaggio viene inviato in modo molto lento o in modo incompleto, bloccando la connessione e impedendo al server di liberare le risorse necessarie per servire altre richieste.

Questo tipo di attacco è particolarmente difficile da rilevare e mitigare, poiché le richieste sembrano legittime, ma richiedono un tempo eccessivo per essere elaborate dal server. Gli attacchi Slow HTTP possono causare tempi di risposta molto lenti o tempi di inattività del server, rendendo impossibile l’accesso ai servizi online ospitati su quel sistema.

Per proteggersi da questi attacchi, le organizzazioni possono implementare soluzioni di sicurezza come l’uso di firewall applicativi (web application firewall o WAF), la limitazione delle connessioni al server e l’utilizzo di sistemi di rilevamento e mitigazione degli attacchi DDoS

L'articolo Gli hacktivisti filorussi di NoName057(16), rivendicano nuovi attacchi alle infrastrutture italiane proviene da il blog della sicurezza informatica.

For most of us, mirrors are something we buy instead of build. However, [Unnecessary Automation] wanted to craft mirrors of his own for a custom telescope build. As it turns out, producing optically-useful mirrors is not exactly easy.

For the telescope build in question, [Unnecessary Automation] needed a concave mirror. Trying to get that sort of shape with glass can be difficult. However, there’s such a thing as a “liquid mirror” where spinning fluid forms into a parabolic-like shape. Thus came the idea to spin liquid resin during curing to try and create a mirror with the right shape.

That didn’t quite work, but it inspired a more advanced setup where a spinning bowl and dense glycerine fluid was used to craft a silicone mold with a convex shape. This could then be used to produce a resin-based mirror in a relatively stationary fashion. From there, it was just necessary to plate a shiny metal layer on to the final part to create the mirror effect. Unfortunately, the end result was too messy to use as a viable telescope mirror, but we learn a lot about what didn’t work along the way.

The video is a great journey of trial and error. Sometimes, figuring out how to do something is the fun part of a project, even if you don’t always succeed. If you’ve got ideas on how to successfully spin cast a quality mirror, drop them in the comments below. We’ve seen others explore mirror making techniques before, too.

youtube.com/embed/rpBV1eQdJxE?…

hackaday.com/2025/06/03/spin-c…

Durante un recente soggiorno in un bellissimo Hotel**** nella splendida Toscana, uno dei membri del nostro team ha vissuto un’esperienza IT a dir poco “agghiacciante”. Nonostante l’ambiente elegante e l’accoglienza impeccabile, il servizio Wi-Fi dell’hotel era vergognoso: il captive portal funzionante a singhiozzi, connessioni instabili e nessuna policy di sicurezza applicata.

Come mostrato nello screen il captive, richiede diversi dati ed in fondo fa notare che la connessione avviene tramite “un’equa distribuzione della banda internet disponibile..”

Parte un messaggio nella chat di gruppo che fa scoppiare lo sfogo generale: il collega toscano che sottolinea quanto sia difficile sensibilizzare le aziende nella sua zona, dove persino le associazioni di categoria spesso “fanno orecchie da mercante”; Gli altri che quasi all’unisono confermano di trovarsi nella stessa situazione nei loro territori; fino ad ammettere che forse il vero problema siamo noi tecnici, incapaci di far comprendere il rischio.

Questo confronto ci ha portato a voler indagare sul fornitore IT di questo “servizio”. Si tratta di un’azienda della zona che nel nome porta orgogliosamente la parola “Cyber”, lasciando intendere competenze avanzate in sicurezza informatica. Ancora più incuriositi abbiamo guardato il loro sito web:

Riscontrando che non veniva aggiornato dal 2016, con un backend ancora in PHP 5.4.16 (cvedetails.com/version/479254/…, 219 vulnerabilità note di cui 35 di code execution) e servizio SSH esposto in rete con OpenSSH 7.4 (cvedetails.com/version/573324/…, qui le cve sono meno 17, ma questa CVE-2023-38408 con punteggio 9.8 dovrebbe essere sufficiente per far comprendere il rischio).

Questi due elementi dovrebbero fare saltare dalla sedia qualsiasi persona che ha un minimo di esperienza IT quindi di base tutti i nostri lettori. Ma ci rendiamo conto che non tutti possono capire e avere idea di cosa stiamo parlando. In questo articolo vogliamo proprio trattare questa parte e evidenziare l’importanza di scegliere un buon fornitore, ma soprattutto come questa scelta e valutazione dovrebbe essere più alla portata di tutti.

Di solito ogni volta quando si acquista qualcosa tendiamo ad analizzare il fornitore più adeguato per quelle che sono le esigenze ma basandosi principalmente su due parametri qualità/prezzo. Mentre il prezzo è facilmente individuabile e identificabile, la qualità diventa qualcosa di difficile se non si è del mestiere. Per questo motivo si è iniziato ad utilizzare sempre di più due elementi come la reputazione e la qualifica. Per esempio quando compriamo qualcosa andiamo sempre a verificare due cose oltre al prezzo:

1. I commenti e reputazioni di quel prodotto
2. Eventuali qualità/qualifiche del prodotto, per esempio in ottica di green o di performance. Per essere comprensibili queste devono essere il più chiare possibile, come per esempio lo sono le etichette della classe energetica degli elettrodomestici (tutti noi sappiamo che un dispositivo in classe A++ è migliore di uno in classe C).

La qualità e i commenti in ambito IT

Come anticipato, quando parliamo di acquisti “tradizionali”, è ormai automatico consultare recensioni online, forum di discussione e comparatori di prezzo per capire se un prodotto vale il costo richiesto. In ambito IT, questo approccio diventa però più complesso, perché dietro al termine “qualità” si celano aspetti tecnici non sempre immediatamente comprensibili a chi non è del mestiere.

Così come esistono etichette energetiche che aiutano i consumatori a valutare l’efficienza degli elettrodomestici, sarebbe auspicabile introdurre un sistema simile per i servizi e prodotti IT. Un’etichetta di sicurezza informatica fornirebbe una valutazione immediata del livello di protezione offerto, facilitando scelte consapevoli anche per chi non ha competenze tecniche.

L’Unione Europea ha avviato iniziative per affrontare questa problematica. Il Cyber Resilience Act (CRA), adottato nel dicembre 2024, stabilisce requisiti obbligatori di sicurezza per i prodotti con elementi digitali, imponendo ai produttori di garantire la protezione dei loro prodotti durante tutto il ciclo di vita. A partire dall’11 dicembre 2027, solo i prodotti conformi a questi standard potranno essere commercializzati nell’UE, identificati dal marchio CE che attesterà anche la conformità ai requisiti di sicurezza informatica.

Parallelamente, l’European Cyber Security Organisation (ECSO) ha introdotto il Cybersecurity Made in Europe Label, un’etichetta che promuove le aziende europee che offrono soluzioni di cybersecurity affidabili e conformi alle normative europee. Sebbene questa etichetta sia un passo avanti, è ancora volontaria e non universalmente adottata.

L’esperienza che viviamo tutti i giorni però evidenzia la necessità urgente di strumenti che permettano anche ai non esperti di valutare facilmente la sicurezza dei servizi digitali. Un sistema di etichettatura chiaro e standardizzato, supportato da normative nazionali o europee, faciliterebbe scelte consapevoli, proteggendo sia i fornitori che i clienti finali da rischi informatici. È fondamentale che le istituzioni europee e nazionali accelerino l’implementazione di tali strumenti, promuovendo una cultura della sicurezza accessibile a tutti.

Sarebbe utile che l’ACN mettesse a disposizione uno strumento basato che tramite un audit che le aziende possono fare in modo volontario e di autocertificazione/dimostrazione, desse a loro come output un livello del loro prodotto/soluzione, stile classe A,B,C degli elettrodomestici.

Ma in attesa cosa possiamo fare?

In mancanza di uno strumento che semplifichi e renda renda accessibile la valutazione di un fornitore IT alla portata di tutti. Vediamo come fare anche se non si si è esperti di IT, sfruttando al meglio la reputazione, i feedback e alcuni criteri oggettivi:

Recensioni e testimonianze (social proof)

• Piattaforme di recensioni: Anche chi non è tecnico può trarre vantaggio da siti come Trustpilot o da forum specializzati (ad esempio Spiceworks o Reddit/r/sysadmin). Qui i professionisti raccontano esperienze reali su modelli di router, firewall, access point o su vendor di servizi gestiti. Con una breve lettura si riesce a capire se un prodotto è soggetto a malfunzionamenti o se un fornitore di servizi ha frequenti interruzioni.
• Case study e referenze: Molte aziende IT pubblicano sul proprio sito casi di studio (case study) che descrivono progetti già realizzati, con numeri concreti e testimonial dei clienti. Valutare se il fornitore ha esperienze simili al proprio settore permette di capire se è davvero in grado di gestire le stesse criticità. L’assenza di case study recenti, o la mancanza di referenze, è un segnale che vale la pena considerare come campanello d’allarme.

Indicatori di qualità misurabili

• Uptime e SLA (Service Level Agreement): Un preventivo serio indica sempre un livello minimo di servizio, ad esempio “uptime garantito al 99,5%” o “tempo massimo di intervento in caso di guasto: 4 ore”. Se il fornitore non menziona l’SLA o non specifica i tempi di intervento, vuol dire che in caso di problema il cliente potrebbe rimanere senza supporto per giorni.
• Aggiornamenti e patch management: Un buon fornitore IT indica con chiarezza la frequenza degli aggiornamenti software e firmware, magari specificando “aggiornamenti mensili” o “patch di sicurezza rilasciate entro 48 ore dalla scoperta”. Se non è indicato nulla, significa che gli aggiornamenti vengono fatti in modo sporadico (o non vengono fatti affatto), lasciando sistemi esposti a vulnerabilità note.

Certificazioni e qualifiche come proxy di affidabilità

• Certificazioni ISO/IEC 27001, 20000, 9001: non tutti sapranno dettagliare ogni punto di questi standard, ma riconosceranno immediatamente che un’azienda certificata ISO/IEC 27001 “ha un sistema organizzato per gestire la sicurezza delle informazioni”. Se un fornitore non è neppure in grado di mostrare un logo di certificazione, è difficile che abbia procedure di gestione del rischio minimamente strutturate.
• Certificazioni di prodotto (Wi-Fi Alliance, UL, CE): Nel caso di dispositivi di rete, un access point “Wi-Fi CERTIFIED 6” ha superato test di interoperabilità, performance e sicurezza. Un router con questo logo è molto più affidabile di uno che dichiara genericamente “compatibile con gli standard più diffusi”.

Forum, community e gruppo di pari: il “passaparola digitale”

• Presenza online e reputazione sui social: Basta una rapida ricerca per capire quanto un’azienda sia attiva e apprezzata. Se trovi post recenti in cui i clienti lodano tempestività e competenza, vuol dire che c’è un riscontro positivo. Al contrario, pagine abbandonate o commenti negativi frequenti senza risposte, indicano scarsa attenzione al cliente.
• Gruppi di settore e community locali: Un albergatore per esempio può entrare in gruppi Facebook, LinkedIn o forum dedicati all’ospitalità (ad esempio “Alberghi e Turismo Italia”) e chiedere direttamente: “Qualcuno ha già lavorato con questo fornitore IT? Esperienze positive o negative?” In poche ore si ottengono feedback reali da chi ha già provato quei servizi.

Confronto tra più offerte e non fermarsi alla prima

• Richiedere almeno tre preventivi diversi: Anche se la prima proposta sembra completa ed economica, è importante chiedere almeno altre due offerte per avere un quadro più ampio. Confronta non solo i costi, ma soprattutto i dettagli: quali servizi sono inclusi, come viene gestito il supporto, quali sono i tempi di intervento e le modalità di aggiornamento.
• Valutare la coerenza delle proposte: Controlla che tutti i preventivi abbiano informazioni simili (SLA, aggiornamenti, certificazioni). Se un fornitore non specifica chiare garanzie o manca di dettagliare il piano di manutenzione, significa che potrebbe esserci un costo nascosto in caso di guasti o vulnerabilità. Scegliere la proposta migliore significa trovare il giusto equilibrio tra prezzo, qualità e affidabilità.

In questo modo, anche chi non è esperto di IT può farsi un’idea solida e prendere decisioni più informate, riducendo al minimo il rischio di affidarsi a un fornitore che alla fine costerà molto di più, tra interruzioni, malfunzionamenti e mancate protezioni.

Perché dovrei dedicare tanto tempo a un aspetto non “core” della mia attività?

Innanzitutto perché, come detto in precedenza, l’assenza di strumenti chiari e accessibili a tutti, per valutare la sicurezza dei servizi digitali rende difficile distinguere un fornitore affidabile da uno che – pur millantando competenze avanzate – non rispetta neanche i requisiti di base. Confidiamo che questa possibilità arrivi al più presto e che enti come l’ACN nazionale possano farsi carico di sviluppare un sistema concreto e alla portata di tutti.

Nel frattempo, però, non possiamo rimanere con le mani in mano: scegliere il partner sbagliato può costarci molto caro, e un servizio apparentemente secondario (come la connessione Wi-Fi da cui siamo partiti) potrebbe generare conseguenze gravissime. Basti pensare a un data breach di una certa entità: il danno reputazionale ed economico per un hotel potrebbe essere tale da compromettere irrimediabilmente la sua attività, fino addirittura alla chiusura.

I dati a conferma del rischio legato a fornitori IT inaffidabili non lasciano dubbi

• 70 attacchi alla supply chain solo nella prima metà del 2024 attestano che le catene di fornitura digitali sono ormai un bersaglio privilegiato per i cybercriminali. enisa.europa.eu.
• Il 23 % delle organizzazioni ha subito almeno un data breach via software supply chain nel 2023, con un’impennata del 241 % rispetto all’anno precedente. Snyk.
• L’81 % delle aziende dichiara di aver subito ripercussioni negative a causa di violazioni nella propria supply chain nell’ultimo anno, seppure si tratti di una lieve diminuzione rispetto al 94 % del 2023. Corporate Compliance Insights.
• Gli attacchi alla supply chain sono aumentati del 431 % fra il 2021 e il 2023 e tutto lascia pensare che questo trend continuerà a salire anche nel 2025insurancebusinessmag.com/us/ne…insurancebusinessmag.com.
• Nel nostro REPORT SULLA MINACCIA RANSOMWARE ITALIA DARK MIRROR Q1 – 2025 – nell’analisi riferita i settori economici più colpiti da attacchi ransomware nel Q1-2025, si evidenziano ben 366 attacchi sui Services (categoria che include, tra gli altri, alberghi e ristorazione) ha avuto un aumento del 36 % confermandosi tra i target principali anche nel 2025.

Estratto dal report DARKMIRROR Q1 2025 di DarkLab
Questi numeri dimostrano in modo lampante che non è più possibile rimandare: imprenditori e albergatori devono avere a disposizione strumenti chiari, immediati e comprensibili per capire in un colpo d’occhio il livello di sicurezza offerto da un fornitore IT.

Conclusioni

Oggi giorno, la qualità dei servizi IT non può essere considerata un elemento secondario in nessun settore. Nell’articolo abbiamo spiegato come un partner IT inadeguato possa intaccare la reputazione, la sicurezza e, in ultima analisi, il successo di un’attività. Non basta più affidarsi al nome o a promesse generiche: ogni persona deve poter capire, in modo semplice e immediato, quanto sia solido e affidabile il fornitore a cui si rivolge.

I dati e le statistiche raccolte confermano che i rischi legati a fornitori IT non all’altezza sono concreti e in crescita. Un solo data breach può tradursi in danni economici e reputazionali tali da compromettere irrimediabilmente l’attività.

La mancanza di consapevolezza e di interesse si evidenzia anche in una delle nostre ultime interviste:

RHC effettua una BlackView con NOVA ransomware: “Aspettatevi attacchi pericolosi”

I cybercriminali sono i primi a sfruttare queste nostre mancanze.

Per questo motivo, è urgente disporre di strumenti che consentano di valutare facilmente e in modo trasparente il livello di protezione offerto da un vendor IT. Il Cyber Resilience Act e il Cybersecurity Made in Europe Label rappresentano passi nella giusta direzione, ma ad oggi non bastano: serve che enti come l’ACN nazionale intervengano rapidamente per sviluppare un sistema di etichettatura basato su audit volontari e autocertificazione, capace di restituire un “voto” chiaro (A, B, C eccetera) alle soluzioni IT. Solo così, imprenditori e albergatori potranno fare scelte consapevoli senza dover diventare esperti di sicurezza.

In un mondo in cui la tecnologia è ormai parte integrante di tutti i servizi, trascurare la sicurezza IT non è più un’opzione: è tempo di fare della protezione digitale una priorità, al pari di un servizio di qualità o di una struttura confortevole.

L'articolo WI-FI da incubo in Hotel a 4 Stelle! Ecco cosa abbiamo scoperto in un weekend da paura proviene da il blog della sicurezza informatica.