EN: The dynamics of #ruscist losses in the war against Ukraine since February 24, 2022
index.minfin.com.ua/en/russian…

UA: Динаміка втрат рашистів у війні проти України з 24 лютого 2022 року
index.minfin.com.ua/ua/russian…

RU: Динамика потерь рашистов в войне против Украины с 24 февраля 2022 года
index.minfin.com.ua/russian-in…

There’s no Rust on this Ironclad Kernel

Rust is the new hotness in programming languages because of how solid its memory protections are. Race conditions and memory leaks are hardly new issues however, and as greybeards are wont to point out, they were kind of a solved problem already: we have Ada. So if you want a memory-protected kernel but aren’t interested in the new kids’ rusty code, you might be interested in the Ironclad OS kernel, written entirely in Ada.

OK, not entirely in classic Ada– they claim to use SPARK, too, but since SPARK and Ada converged syntax-wise over a decade ago, we’re just going to call it Ada. The SPARK toolchain means they can get this kernel “formally-verified” however, which is a big selling point. If you’re not into CS, that just means the compiler can confirm the code is going to do what we want under all possible conditions — which is a nice thing to be able to say about the heart of your operating system, I think we can all agree. It’s a nice thing to be able to say about any code, which is one reason why you might want to be programming in Ada.

It’s also not something we can say without qualifications about Ironclad OS, as the verification process is still ongoing. Still, that lofty goal certainly sets Ironclad apart from other POSIX kernel projects.

Yes, the Ironclad OS kernel is POSIX compliant, like its Rust-based equivalent Redox OS. While it would be nice to see some innovation outside the POSIX box (outside of whatever Redmond’s doing these days), making the kernel POSIX-compliant certainly makes it a lot more useful. The Ironclad OS kernel is fully open source under GPLv3, with no binary blobs built in. The OSF will like that, and the rest of us should be able to tack on the binary blobs needed to run our hardware as usual, so it’s win-win.

They’re currently targeting RISC-V and x86, with test platforms being MilkV and LattePanda SBCs. If someone was willing to take on the project single-handedly, they could probably strongarm the project into supporting other architectures, if there’s are any other SBCs popular these days. PowerPC, perhaps?

For the supported architectures, there is already a usable (for some values of the word) distribution in the form of Gloire, which is appropriately named after the first ocean-going Ironclad vessel. The header image is a screenshot from an X-server on running on that distribution.

hackaday.com/2025/11/12/theres…

Cheap Multimeter Gets Webified

[Mellow Labs] wanted to grab a multimeter that could do Bluetooth. Those are cheap and plentiful, but the Bluetooth software was, unsurprisingly, somewhat lacking. A teardown shows a stock Bluetooth module. A quick search found a GitHub with software. But then he had a fiendish idea: could you replace the Bluetooth module with an ESP32 and use WiFi instead of Bluetooth?

This was as good an excuse as any to buy a cheap logic analyzer. Armed with some logic captures, it was easy to figure out how to fake the meter into thinking a Bluetooth client was connected.

Oddly enough, the data is “encrypted” with XOR, and an AI website was able to identify the raw data versus the encrypted data and deduce the key. The rest, as they say, was software. Well, except for one hardware problem: The ESP32 needed more power, but that was a fairly simple fix.

The entire thing fit the case beautifully. Now the meter streams a web page instead of requiring Bluetooth. Great job!

If your meter isn’t handheld, you can still play a similar trick. Just don’t forget that when it comes to meters, you often get what you pay for. Not that you can’t do a similar hack on an expensive meter, either.

youtube.com/embed/IDr2Icdue40?…

hackaday.com/2025/11/12/cheap-…

2025 Component Abuse Challenge: Light an LED With Nothing

Should you spend some time around the less scientifically informed parts of the internet, it’s easy to find “Free power” stories. Usually they’re some form of perpetual motion machine flying in the face of the laws of conservation of energy, but that’s not to say that there is no free power.

The power just has to come from somewhere, and if you’re not paying for it there’s the bonus. [joekutz] has just such a project, lighting up LEDs with no power source or other active electronics.

Of course, he’s not discovered perpetual motion. Rather, while an LED normally requires a bit of current to light up properly, it seems many will produce a tiny amount of light on almost nothing. Ambient electromagnetic fields are enough, and it’s this effect that’s under investigation. Using a phone camera and a magnifier as a light detector he’s able to observe the feeble glow as the device is exposed to ambient fields.

In effect this is using the LED as the very simplest form of radio receiver, a crystal set with no headphone and only the leads, some wires, and high value resistors as an antenna. The LED is after all a diode, and it can thus perform as a rectifier. We like the demonstration even if we can’t quite see an application for it.

While we’re no longer taking new entries for the 2025 Component Abuse Challenge, we’ve still got plenty of creative hacks from the competition to show off. We’re currently tabulating the votes, and will announce the winners of this particularly lively challenge soon.

hackaday.com/2025/11/12/2025-c…

FLOSS Weekly Episode 854: The Big Daddy Core

This week Jonathan and Ben chat with Jason Shepherd about Ocre and Atym.io! That’s the lightweight WebAssembly VM that lets you run the same containers on Linux and a host of embedded platforms, on top of the Zephyr embedded OS. What was the spark that led to this project’s creation, what does Atym.io bring to the equation, and what are people actually doing with it? Watch to find out!

• lfedge.org/projects/ocre/
• lfedge.org/from-the-magical-my…
• atym.io/
• linkedin.com/company/atym-inc
• atym.io/discord

youtube.com/embed/MoN2rTCmUKI?…

Did you know you can watch the live recording of the show right on our YouTube Channel? Have someone you’d like us to interview? Let us know, or have the guest contact us! Take a look at the schedule here.

play.libsyn.com/embed/episode/…

Direct Download in DRM-free MP3.

If you’d rather read along, here’s the transcript for this week’s episode.

Places to follow the FLOSS Weekly Podcast:

• Spotify
• RSS

Theme music: “Newer Wave” Kevin MacLeod (incompetech.com)

Licensed under Creative Commons: By Attribution 4.0 License

hackaday.com/2025/11/12/floss-…

Radio Apocalypse: Survivable Low-Frequency Communication System

In the global game of nuclear brinksmanship, secrets are the coin of the realm. This was especially true during the Cold War, when each side fielded armies of spies to ferret out what the other guy was up to, what their capabilities were, and how they planned to put them into action should the time come. Vast amounts of blood and treasure were expended, and as distasteful as the whole thing may be, at least it kept armageddon at bay.

But secrets sometimes work at cross-purposes to one’s goals, especially when one of those goals is deterrence. The whole idea behind mutually assured destruction, or MAD, was the certain knowledge that swift retaliation would follow any attempt at a nuclear first strike. That meant each side had to have confidence in the deadliness of the other’s capabilities, not only in terms of their warheads and their delivery platforms, but also in the systems that controlled and directed their use. One tiny gap in the systems used to transmit launch orders could spell the difference between atomic annihilation and at least the semblance of peace.

During the height of the Cold War, the aptly named Survivable Low-Frequency Communication System was a key part of the United States’ nuclear deterrence. Along with GWEN, HFGCS, and ERCS, SLFCS was part of the alphabet soup of radio systems designed to make sure the bombs got dropped, one way or another.

Skipping the Skip

Nuking the atmosphere, for science. The Starfish Prime tests showed how easily one could deprive one’s enemy of the use of the ionosphere. Source: USAF 1352nd Photographic group, public domain.
The hams have a saying: “When all else fails, there’s amateur radio.” It’s true, but it comes with a huge caveat, since hams rely on the ionosphere to bounce their high-frequency (HF) signals around the world. Without that layer of charged particles, their signals would just shoot off into space instead of traveling around the world.

For the most part, the ionosphere is a reliable partner in amateur radio’s long-distance communications networks, to the point that Cold War military planners incorporated HF links into their nuclear communications systems. But since at least the Operation Argus and Operation Hardtack tests in 1958, the United States had known about the effect of high-altitude nuclear explosions on the ionosphere. Further exploration of these effects through the Starfish Prime tests in 1962 revealed just how vulnerable the ionosphere is to direct attack, and how easy it would be to disrupt HF communications networks.

The vulnerability of the ionosphere to attack was very much in the minds of U.S. Air Force commanders during the initial design sessions that would eventually lead to SLFCS. They envisioned a system based on the propagation characteristics of the EM spectrum at lower frequencies, in the low-frequency (LF) and very-low-frequency (VLF) bands. While wavelengths in the HF part of the spectrum are usually measured in meters, LF and VLF waves are better measured in kilometers, ranging between 1 and 100 kilometers.

At these wavelengths, radio behaves very differently than they do further up the dial. For LF signals (30 to 300 kHz), the primary mode of propagation is via ground waves, in which signals induce currents in the Earth’s surface. These currents tend to hug the surface, bending with its curvature and propagating long distances. For VLF signals (3 to 30 kHz), Earth-ionosphere waveguide propagation dominates. Thanks to their enormous wavelengths, which are comparable to the typical altitude of the lowest, or D-layer, of the ionosphere, the waves “see” the space between the ground and the ionosphere as a waveguide, which forms a low-loss path that efficiently guides them around the globe.

Critically for the survivability aspect of SLFCS, both of these modes are relatively immune to the ionospheric effects of a nuclear blast. That’s true even for VLF, which would seem to rely on an undisturbed ionosphere to form the “roof” of the necessary waveguide, but the disruption caused by even a large blast is much smaller than their wavelengths, rendering any changes to the ionosphere mostly invisible to them.

Big Sticks

Despite the favorable propagation modes of LF and VLF for a communications system designed to survive a nuclear exchange, those long wavelengths pose some challenges. Chief among these is the physical size of the antennas necessary for these wavelengths. In general, antenna size is proportional to wavelength, which makes the antennas for LF and VLF quite large, at least on the transmitting side. For SLFCS, two transmission sites were used, one at Silver Creek, Nebraska, and another in the middle of the Mojave Desert in Hawes, California. Since ground wave propagation requires a vertically polarized signal, each of these sites had a guyed mast radiator antenna 1,226 feet (373 meters) tall.

While the masts and guy wire systems were as reinforced as possible, there’s only so much that can be done to make a structure like that resist a nuke. Still, these structures were rated for a “moderate” nuclear blast within a 10-mile (16-km) radius. That would seem to belie the “survivable” goal of the system, since even at the time SLFCS came online in the late 1960s, Soviet ICBM accuracy was well within that limit. But the paradox is resolved by the fact that SLFCS was intended only as a backup method of getting launch orders through to ICBM launch facilities, to be used to launch a counterattack after an initial exchange that hit other, more valuable targets (such as the missile silos themselves), leaving the ionosphere in tatters.

The other challenge of LF/VLF communications is the inherently low data transfer rates at these frequencies. LF and VLF signals only have perhaps a kilohertz to as few as a few hertz of bandwidth available, meaning that they can only encode data at the rate of a few tens of bits per second. Such low data rates preclude everything but the most basic modulation, such as frequency-shift keying (FSK) or its more spectrally efficient cousin, minimum-shift keying (MSK). SLFCS transmitters were also capable of sending plain old continuous wave (CW) modulation, allowing operators to bang out Morse messages in a pinch. When all else fails, indeed.

No matter which modulation method was used, the idea behind SLFCS was to trade communications speed and information density for absolute reliability under the worst possible conditions. To that end, SLFCS was only intended to transmit Emergency Action Messages (EAMs), brief alphanumeric strings that encoded specific instructions for missile commanders in their underground launch facilities.

Buried Loops

SLFCS receiver equipment giving off Fallout vibes in the Oscar-Zero launch control center at the Ronald Reagan Minuteman Missile State Historic Site.
While the transmitting side of the SLFCS equation was paradoxically vulnerable, the receiving end of the equation was anything but. These missile alert facilities (MAFs), sprinkled across the upper Midwest, consisted of ten launch facilities with a single Minuteman III ICBM in an underground silo, along with one underground launch control center, or LCC. Above ground, the LCC sports a veritable antenna farm representing almost the entire RF spectrum, plus a few buried surprises, such as the very cool HFGCS antenna silos, which can explosively deploy any of six monopole antennas up from below ground to receive EAMs after the LCC has gotten its inevitable nuking.

The other subterranean radio surprise at LCCs is the buried SLFCS antenna. The buried antenna takes advantage of the induced Earth currents in ground wave propagation, and despite the general tendency for LF antennas to be large is actually quite compact. The antennas were a magnetic loop design, with miles of wire wrapped around circular semi-rigid forms about 1.5 meters in diameter. Each antenna consisted of two loops mounted orthogonally, giving the antenna a globe-like appearance. Each loop of the antenna was coated with resin to waterproof and stiffen the somewhat floppy structure a bit before burying it in a pit inside the LCC perimeter fence. Few examples of the antenna exist above ground today, since most were abandoned in place when SLFCS was decommissioned in the mid-1980s. One SLFCS antenna was recently recovered, though, and is currently on display at the Titan Missile Museum in Arizona.

youtube.com/embed/VkNHlF6pEmM?…

Sign of the Times

Like many Cold War projects, the original scope of SLFCS was never fully realized. The earliest plans called for around 20 transmit/receive stations, plus airplanes equipped with trailing wire antennas over a mile long, and more than 300 receive-only sites across the United States and in allied countries. But by the time plans worked their way through the procurement process, technology had advanced enough that military planners were confident that they had the right mix of communications modes for the job. In the end, only the Nebraska and California transmit/receive sites were put into service, and even the airborne transmitters idea was shelved thanks to excessive drag caused by that long trailing wire. Still, the SLFCS towers and the buried loop antennas stayed in service until the mid-1980s, and the concept of LF and VLF as a robust backup for strategic comms lives on with the Air Force’s Minimum Essential Emergency Communications Network.

hackaday.com/2025/11/12/radio-…

Breve Storia dei malware: l’evoluzione delle specie dalle origini ai nostri giorni

All’inizio si parlava di “virus” poi sono comparsi i “worm” seguiti poi dai “macro virus”.

A questi si sono presto affiancati altri tipi di software ostili come i keylogger o i locker.

Ad un certo punto abbiamo tutti iniziato a chiamarli più genericamente malware.

E proprio come i virus biologici, i malware si sono evoluti nel tempo; alcuni, sono altamente opportunisti, compaiono per sfruttare opportunità a breve termine mentre altri si sono evoluti per sfruttare difetti e problemi più fondamentali presenti nei sistemi IT che non sono ancora stati risolti.

Da Creeper a moderni Ransomware

I primi virus della storia informatica risalgono agli anni 70/80. Il primo malware della storia informatica è stato Creeper, un programma scritto per verificare la possibilità che un codice potesse replicarsi su macchine remote.

Il programma chiamato Elk Cloner è invece accreditato come il primo virus per computer apparso al mondo. Fu creato nel 1982da Rich Skrenta sul DOS 3.3 della Apple e l’infezione era propagata con lo scambio di floppy disk: il virus si copiava nel settore di boot del disco e veniva caricato in memoria insieme al sistema operativo all’avvio del computer.

Nel corso degli anni ottanta e nei primi anni novanta, Con la proliferazione dei floppy disk si ebbe una notevole diffusione dei virus, infatti una pratica assai comune era lo scambio di floppy in ogni ambito lavorativo .Bastavano pochi floppy infetti per far partire un attacco su vasta scala

Dalla metà degli anni novanta, invece, con la diffusione di internet, i virus ed i cosiddetti malware in generale, iniziarono a diffondersi assai più velocemente, usando la rete e lo scambio di e-mail come fonte per nuove infezioni.

Il primo virus informatico che si guadagnò notorietà a livello mondiale venne creato nel 1986 da due fratelli pakistani proprietari di un negozio di computer per punire, secondo la loro versione, chi copiava illegalmente il loro software. Il virus si chiamava Brain, si diffuse in tutto il mondo, e fu il primo esempio di virus che infettava il settore di avvio del DOS.

Il primo file infector invece apparve nel 1987. Si chiamava #Lehigh e infettava solo il file command.com. Nel 1988 Robert Morris Jr. creò il primo #worm con diffusione su internet, il Morris worm. L’anno seguente, nel 1989, fecero la loro comparsa i primi virus polimorfi, con uno dei più famosi: Vienna, e venne diffuso il trojan AIDS (conosciuto anche come Cyborg), molto simile al trojan dei nostri giorni chiamato PGPCoder. Entrambi infatti codificano i dati del disco fisso chiedendo poi un riscatto all’utente per poter recuperare il tutto( il funzionamento è lo stesso degli attuali #Ransomware).

Nel 1995 il primo macrovirus, virus scritti nel linguaggio di scripting di programmi di Microsoft come Word ed Outlook che infettano soprattutto le varie versioni dei programmi Microsoft attraverso lo scambio di documenti. Concept fu il primo macro virus della storia.

Nel 2000 il famosoI Love Youche diede il via al periodo degli script virus.

Sono infatti i più insidiosi tra i virus diffusi attraverso la posta elettronica perché sfruttano la possibilità, offerta da diversi programmi come Outlook e Outlook Express di eseguire istruzioni attive (dette script), contenute nei messaggi di posta elettronica scritti in HTML per svolgere azioni potenzialmente pericolose sul computer del destinatario.

I virus realizzati con gli script sono i più pericolosi perché possono attivarsi da soli appena il messaggio viene aperto per la

lettura. I Love You si diffuse attraverso la posta elettronica in milioni di computer di tutto il mondo, al punto che per l’arresto del suo creatore, un ragazzo delle Filippine, dovette intervenire una squadra speciale dell’FBI.

Era un messaggio di posta elettronica contenente un piccolo programma che istruiva il computer a rimandare il messaggio appena arrivato a tutti gli indirizzi contenuti nella rubrica della vittima, in questo modo generando una specie di catena di sant’Antonio automatica che saturava i server di posta.

Dal 2001 si è registrato un incremento di worm che, per diffondersi, approfittano di falle di programmi o sistemi operativi senza bisogno dell’intervento dell’utente. L’apice nel 2003 e nel 2004: SQL/Slammer, il più rapido worm della storia – in quindici minuti dopo il primo attacco, Slammer aveva già infettato metà dei server che tenevano in piedi internet mettendo fuori uso i bancomat della Bank of America, spegnendo il servizio di emergenza 911 a Seattle e provocando la cancellazione per continui inspiegabili errori nei servizi di biglietteria e check-in di alcune compagnie aeree; ed i due worm più famosi della storia: Blaster e Sasser.

Nel gennaio 2004 compare MyDoom, worm che ancora oggi detiene il record di velocità di diffusione nel campo dei virus. Anche in questo caso il vettore di contagio è la posta elettronica: MyDoom, infatti, altro non è che un tool appositamente sviluppato (su commissione) per inviare spam. E, stando alle statistiche, ha svolto molto bene il suo lavoro.

Nel 2007, invece, nascono e si diffondono Storm Worm e Zeus. Il primo è un trojan horse altamente virale (si pensa che abbia infettato decine di milioni di macchine) che permette ad un hacker di prendere il controllo del computer infetto e aggiungerlo alla rete botnet Storm.

Il secondo, invece, colpisce sistemi informatici basati su Microsoft Windows ed è ideato per rubare informazioni di carattere bancario (credenziali per accedere al conto corrente e dati della carta di credito).

Dal 2010 in poi, gli anni della #cyberwar. La sempre maggiore diffusione di computer e altri dispositivi informatici rende i virus e i malware delle vere e proprie armi a disposizione delle maggiori potenze mondiali. Lo dimostra il virus Stuxnet, un trojan che si diffonde nella seconda parte dell’anno e da molti ritenuto un’arma per colpire i sistemi informatici delle centrali nucleari iraniane. Nel 2012 viene scoperto Flame, malware utilizzato, probabilmente, in azioni di spionaggio in alcuni Paesi del Medio Oriente e scoperto da alcuni informatici iraniani.

Nel medesimo anno cominciò a diffondersi nel 2012. Basato sul trojan Citadel (che era a sua volta basato sul trojan Zeus), il suo payload mostrava un avviso che sembrava provenire dalla polizia federale (da cui prese il nome “trojan della polizia”), affermando che il computer era stato utilizzato per attività illegali (ad esempio per il download di software pirata o di materiale pedopornografico).

L’avviso informava l’utente che per sbloccare il loro sistema avrebbe dovuto pagare una multa usando un voucher di un servizio di credito prepagato anonimo, per esempio

o Paysafecard. Per rendere maggiore l’illusione che il computer fosse sotto controllo della polizia federale, lo schermo mostrava anche l’Indirizzo IP della macchina, e alcune versioni mostravano addirittura dei filmati della webcam del PC per far sembrare che l’utente fosse anche ripreso dalla polizia.

Nonostante l’apertura di un nuovo fronte, i normali internauti restano i bersagli preferiti dei creatori di virus. Lo dimostra il malware Cryptolocker, comparso per la prima volta nel 2013 e ancora attivo , anche se con altre forme e altri nomi .

Nel 2014 si è assistito alla proliferazione del trojan Sypeng che era in grado di rubare i dati delle carte di credito, di accedere al registro delle chiamate, alla messaggistica, ai segnalibri del browser e ai contatti. Il malware è stato inizialmente diffuso nei paesi di lingua russa, ma a causa della particolare dinamica della sua distribuzione, ha messo a rischio milioni di pagine web che utilizzano AdSense per visualizzare messaggi pubblicitari. Diffuso via Internet, dà modo agli hacker di crittografare tutti i dati contenuti nel disco rigido e chiedere un riscatto vero e proprio per ottenere il codice di sblocco.

Evoluzione dei Ransomware – Sophos 2020 Threat Report – sophos.com/threatreport2020

Non solo Ransomware!

Dopo i fatti di cronaca del 2019 il ransomware è diventato sicuramente il tipo di malware più noto e più temuto. Mentre molte persone potrebbero non sapere esattamente che un Bot o un RAT lo sono, praticamente tutti hanno sentito storie orribili di interi comuni, aziende o fornitori di servizi sanitari bloccati da ransomware. Potrebbero non sapere esattamente di cosa si tratta, ma sanno che è un problema attuale per qualche motivo.

Anche se i ransomware occupano la maggior parte del palcoscenico (in particolare sulla stampa generalista) non sono l’unica minaccia. Anche Keylogger, Data Stealer, RAM crapers, Bot, Banking Trojan e RAT continuano ad essere protagonisti di molti incidenti di sicurezza e provocare danni rilevanti.

Keyloger

I keyloggers sono sorprendentemente semplici ed allo stesso tempo estremamente efficaci e pericolosi. Si agganciano al flusso di dati provenienti dalle nostre tastiere, questo permette di intercettare tutto ciò che viene scritto. Il bersaglio principale sono solitamente le credenziali di accesso, ma questi malware possono intercettare anche altri tipi di informazione.

Possono essere implementati in molti modi diversi sia hardware che software. Ad esempio ne esistono alcuni progettati per essere nascosti nel connettore USB del cavo della tastiera.

DATA STEALERS

“Data Stealers”, è il nome generico utilizzato per definire qualsiasi malware che entra nella nostra macchina e va a caccia nel nostro disco rigido, e forse anche in tutta la nostra rete, se possibile, alla ricerca di file che contengano dati che valgono qualcosa per i criminali.

RAM SCRAPERS

I malware non riescono sempre a trovare ciò che vogliono nei file presenti sul nostro computer, anche se il malware ha accesso come amministratore o root. Questo perché i dati utili potrebbero esistere solo temporaneamente nella memoria prima di essere deliberatamente cancellati senza mai essere scritti su disco.

Ad esempio la memorizzazione permanente di alcuni dati è ora vietata da regolamenti come PCI-DSS, che è lo standard di sicurezza dei dati del settore delle carte di pagamento.

Però i computer DEVONO, ad esempio, disporre di una chiave privata nella RAM per eseguire la decodifica. I dati segreti DEVONO esistere temporaneamente nella RAM, anche se solo per un breve periodo. Perciò ,cose come chiavi di decrittazione, password in chiaro e token di autenticazione di siti Web sono i tipici bersagli dei RAM scrapers.

BOT

Il bot è un programma che accede alla rete attraverso lo stesso tipo di canali utilizzati dagli utenti umani (per esempio che accede alle pagine Web, invia messaggi in una chat, si muove nei videogiochi, e così via). Programmi di questo tipo sono diffusi in relazione a molti diversi servizi in rete, con scopi vari, ma in genere legati all’automazione di compiti che sarebbero troppo gravosi o complessi per gli utenti umani.Fondamentalmente un bot stabilisce una backdoor semi-permanente in un computer in modo che gli attaccanti possano inviare comandi ovunque si trovino.

Una raccolta di bot viene chiamata botnet. L’altro termine popolare per “Bot” è “Zombi” perché possono anche agire un po ‘come agenti dormienti. I bot comprendono l’invio di carichi di spam dal tuo indirizzo IP, la ricerca di file locali, l’annullamento delle password, l’esplosione di altre macchine su Internet con inondazioni di traffico e persino il clic sugli annunci online per generare entrate pay-per-click.

BANKING TROJANS

I Trojan bancari meritano la loro sottoclasse di malware a causa della loro specializzazione. Si rivolgono esclusivamente alle informazioni bancarie online della vittima. I trojan bancari in genere includono un componente keylogger, per catturare le password mentre vengono immesse e un componente di furto di dati trovare password non crittografate o dettagli dell’account.

RATS

Il RAT – abbreviazione di Remote Access Trojan – ha molto in comune con un “bot”, ma differisce da questo perchè non fa parte di una massiccia campagna per vedere quanti “bot” possono essere richiamati e gestiti per eventi di attacco di massa .

Solitamente i RAT sono impiegati in attacchi più mirati e potenzialmente per eseguire un intrusione dannosa. Possono catturare screenshot, ascoltare l’audio delle nostre stanze attraverso il microfono del PC e accendere le nostre webcam.

youtube.com/embed/iqF3t7ym3xo?…

L'articolo Breve Storia dei malware: l’evoluzione delle specie dalle origini ai nostri giorni proviene da Red Hot Cyber.