© Peter Morrison/Associated Press
Security is not a point-in-time exercise. It’s a cycle of testing, fixing, and starting over. Organisations that treat it as anything less quickly fall behind.
In the last decade, we’ve seen how offensive security practices such as penetration testing, combined with follow-up patching and mitigation strategies, have significantly strengthened defences. For instance, Active Directory hardening, EDR solutions, and endpoint security have evolved considerably thanks to insights from attack simulations.
Repeated internal testing followed by corrective actions will help reduce misconfigurations, close or reduce privilege gaps, and ultimately shrink the overall attack surface. A positive outcome of defensive maturity is that attackers often now have to spend more effort to execute a successful attack.
Modern Attackers Have an Easy Entry
Many significant attacks in 2025 didn’t rely on basic exploit methods alone to reach their end goal. Multiple techniques, including social engineering, MFA fatigue, misconfigured cloud services, token abuse, and trusted third-party access were also used to enable lateral movement.
For instance, Salesforce suffered a breach related to SalesLoft-Drift SaaS, now considered the largest SaaS supply chain breach in history. ShinyHunters/UNC6395, started with the exploitation of a vulnerability in an integration point between Drift and Salesforce. Once inside, attackers were able to get oAuth tokens and refresh tokens for hundreds of companies globally.
And, an attack against Marks & Spencer was one of a number of attacks on major UK retail outlets. The attack happened when malefactors used social engineering tactics and compromised third-party access to trick the retailer’s service desk employees into resetting their own user ID and password for the company’s internal systems.
As attackers evolve to incorporate varying techniques to reach their end goal, the security industry must continue to do the same.
Real Attackers Don’t Respect Security Silos
Whether mass exploitation or a targeted attack, the bad guys are often patient, taking their time to understand the victim’s environment before trying to break in. Stronger defences have the ability to delay or even thwart these attempts, many of which exist because offensive security exposed where defences were weakest, pointing out how attackers might get in, where their controls could fail, and how small issues together can add up to major risks.
Because offensive security is an ecosystem rather than a single activity, network, cloud, identity, and email attack paths all intersect. If you only test one of these environments in isolation, then you are missing how real attacks happen. A mature offensive security programme reflects this reality by using tooling and expertise to test across environmental and stage-level attacks.
As a result, an organisation’s offensive security suite should consist of a full-scale array of tools and services that help companies conduct proactive assessments of their defensive posture. This is tested using several methods including penetration testing, Red Team engagements, and Adversary Simulation to identify vulnerabilities, verify controls, and enhance an entity’s security posture.
We also now have tools and techniques to simulate AI-assisted attacks, targeted cloud abuse, and advanced phishing scenarios that conventional defences cannot stop. These capabilities extend and augment penetration testing and red teaming by helping teams test situations that were onerous or time-consuming to recreate a few years ago.
Change as the Main Goal of Testing
Offensive security is often misunderstood as purely a vulnerability-finding exercise. In practice, its value lies in context.
Penetration testing and adversary simulation provide real-world evidence of how vulnerabilities can impact a company’s overall resilience by showing whether segmentation can prevent an attacker from moving around the network, whether endpoint controls will slow them down, and whether or not the alerts will get to the right person at the right time. The insights from these tests can directly influence changes to network architectures, configurations for endpoints, and identity strategies.
Testing is only valuable as offensive security though if the results are used to create actionable recommendations that result in actual change. These fixes must, in turn, be tested to ensure they are effective. This very feedback loop converts testing into a resilient process.
A Human – Machine Balance
Today’s adversaries use a combination of automation and human insight. Examples of this include using AI to create phishing content, automated scanning and reconnaissance techniques, as well as scripted methods to exploit vulnerabilities. All of these are coordinated and controlled by a person who can assess and adjust the course if one method fails.
This is why defenders must operate similarly.
Most modern attacks are successful due to human factors. A hasty decision, a missed configuration change, or a patch applied too late. Offensive security has strengthened technical controls to the point that people are now the simplest way into a business.
This means there needs to be a balance between automation and human intelligence. Automation can provide rapid scale and consistency, while human expertise provides intuitive reasoning, creative problem solving, and a level of critical thinking and judgment.
Effective offensive security programmes will always use automation to rapidly evaluate large volumes of data and identify potential vulnerabilities and areas of risk and will use human expertise to analyse and understand the results from these evaluations, examine the edge cases, and see through the eyes of a bad actor.
Closing the Loop
Offensive security doesn’t work on its own. It should be part of the defence-in-depth strategy together with security awareness and detection and response.
Threat intelligence proves priority. Knowing that a vulnerability has been identified is helpful, but realising it’s being exploited changes priority. Training employees limits repeated exposures to common attack vectors, while an automated response facilitates immediate actions when required.
Organisations that use offensive security demonstrate maturity and improve their overall security posture by integrating these solutions into their broader security operations and shifting from being reactive to continuously improving.
So, Is Offensive Security Keeping Pace?
Yes, but again, not all by itself.
Offensive security has matured substantially. Threat actors are using more sophisticated and realistic tactics, tools have improved in capability, and the insights these solutions provide are more actionable than ever.
Properly implemented, it can keep pace with attackers as they hone their craft. There is no silver bullet, so the solutions that gain your trust will be those that can be incorporated into a disciplined process of testing, learning, and adapting.
Offensive security is most effective when used from the outset, as a catalyst that leads to better decision-making, more effective controls, and quicker responses.
The post Is Offensive Security Keeping Up with the Latest Cyber Attacks? appeared first on IT Security Guru.
4 min read
NASA’s experimental X-59 aircraft marked a major milestone Friday, June 5, when it flew faster than the speed of sound for the first time, setting the stage for demonstrating its quiet supersonic capabilities later this year.
NASA test pilot Jim “Clue” Less took off and landed at Edwards Air Force Base in California, reaching a top speed of approximately Mach 1.1 (713 mph) and altitude of 43,400 feet. The X-59’s flight began at 11:08 a.m. PDT and lasted 81 minutes, with the team focusing on flying qualities at both subsonic and then supersonic speeds.
jared isaacman
NASA Administrator
”X-59 is getting ready for its quiet supersonic debut. Since the aircraft’s first flight on Oct. 28, 2025, the team has made tremendous progress, flying 16 times in the last 90 days and getting into a steady test rhythm. In the coming days, we expect to take the next step and push to Mach 1.4,” said NASA Administrator Jared Isaacman “I’m grateful to the NASA team and Lockheed Martin Skunk Works for their help getting us to this point, and I hope this is the first of many collaborations as we rebuild NASA’s X-plane portfolio.”
The X-59 is designed to fly at supersonic speeds while creating only a quiet thump instead of a loud sonic boom. For this flight, a NASA F‑15 chase plane flew nearby to monitor the X‑59. The loud sonic booms from the F-15 obscured any sound made by the X-59.
“The X-59’s first supersonic flight is a testament to America’s enduring leadership in science, engineering, and aerospace innovation,” said Michael Kratsios, Assistant to the President for Science and Technology and Director of the Office of Science and Technology Policy. “This achievement comes as the Trump Administration continues work to unleash supersonic flight and enable American ingenuity.”
This first supersonic flight is a significant milestone, but an event even more critical to the mission is upcoming. In just days, the aircraft is expected to make its first “mission conditions” flight, reaching a cruising speed of Mach 1.4 (925 mph) and altitude of approximately 55,000 feet. The X-59 also will be accompanied by a chase plane for this flight.
This speed and altitude are the base conditions for the X-59 when it will eventually fly over several U.S. communities enabling NASA to gather data about how people may perceive its quiet thump. NASA will share this data with U.S. and international regulators to help establish new data-driven noise standards to enable a future viable market for supersonic commercial flight over land.
For the last several months, the X-59 has been participating in an ongoing series of flights where the plane has been flying at a wide range of speeds and altitudes – a process known as envelope expansion. These tests are the first phase of the X-59’s flight testing. They are focused on performance and involve chase plane monitoring. When the aircraft completes this phase it will enter another, focused on its sound profile in order to verify its quiet thump capability.
The X-59 is the centerpiece of NASA’s Quesst mission, which aims to demonstrate quiet supersonic flight and help enable commercial supersonic flight over land worldwide. These advancements will help travelers reach their preferred destinations faster, spending less time in the air.
Through Quesst’s development of the X-59, NASA also will deliver design tools and technology for quiet supersonic airliners that will achieve the high speeds desired by commercial operators without disturbing people on the ground. NASA will validate design tools through ground and flight testing, providing U.S. aircraft manufacturers the ability to explore new quiet supersonic concepts, and provide them with confidence that their resulting designs will meet quiet flight requirements.
4 min read
From high‑speed research flights to high‑altitude science campaigns, NASA depends on aircraft that perform at their best and the ground crews who keep them mission ready.
At NASA’s Armstrong Flight Research Center in Edwards, California, specially trained maintenance crews are essential to keeping the agency’s aircraft flying safely and reliably.
This year, NASA added two F-15s and a Pilatus PC-12 to its fleet at Armstrong. These aircraft – alongside platforms such as the high-altitude ER-2s and NASA’s newest X-plane, the X-59 – reflect a wide range of capabilities. The maintenance staff is responsible for keeping each one mission ready.
“That’s the beauty of our Armstrong maintenance teams. They adapt to any type of change,” said Jose “Manny” Rodriguez, NASA Armstrong Gulfstream G-IV crew chief. “One day you could have an instrument being loaded, and the next day it may be aircraft reconfiguration, all while other aircraft systems may need fixing. They adapt and they overcome any situation.”
Each aircraft supports a specific mission, whether it’s conducting science research, serving as a support or chase aircraft, or assisting NASA rocket launches. The aircraft fly at different speeds, carry specialized hardware, and require maintenance crews to stay agile with fast-paced changes.
To ensure NASA can make aeronautics and science advancements safely, the crews work continuously, checking on the ejection seats, filling the tanks with fuel, and changing out brakes, wheels, wiring, and hardware constantly, all of which can degrade with each flight.
On any given day, an aircraft may be flight-ready for a mission, undergoing scheduled maintenance or modifications, or down for longer-term care.
There are typically multiple NASA Armstrong aircraft in the air in one day. Currently, the center’s C-20A is flying in Peru and Panama, the X-59 is often flying twice per day with a chase plane, and the center’s ER-2 is flying in Colorado, supporting the Geological Earth Mapping Experiment (GEMx). All this work is happening at the same time, and Armstrong’s skilled maintenance staff is prepping and fixing aircraft as needed along the way.
The team includes mechanics with both military and civilian backgrounds, and the job involves a lot of on-the-job training.
Maintenance crews are composed of:
After the maintenance crew ensures the aircraft is in the best condition possible, the team tows it out to the flightline, and it becomes ready for operations. The NASA pilot assigned to the mission will walk around the aircraft with the assigned crew chief for a final safety check before flight.
“There is a crew chief assigned to every aircraft,” Rodriguez said. “The crew chief is responsible for the integrity of that aircraft, and at the end of the day, his signature and the pilot’s together are what constitutes that the aircraft is safe for flight.”
Maintenance crews track each flight to help ensure it completes the mission without returning early. If an aircraft does return to base early, the maintenance team stands ready. When it lands, the crew is right there again, helping the research team complete the mission and fixing whatever is needed to stay nimble and ready for the next flight.
“It’s difficult at times to work with different airplanes from both the civilian and military sides, but it’s very rewarding to see that we have the capability and the expertise to keep these aircraft flying,” Rodriguez said.
4 min read
There’s no sign reading “home sweet home” in the hangar where the X‑59 now sits, but the sentiment is unmistakable among those tending to the quiet supersonic aircraft.
Located at NASA’s Armstrong Flight Research Center in Edwards, California, the X-59 hangar was built in 1968 but looks like new thanks to a full renovation and modernization. While the X-59 was being assembled in Palmdale, California, workers at NASA Armstrong gutted the hangar, adding new electrical wiring, a fire suppression system, office space, air conditioning, and other safety features.
“The whole team is incredibly proud of what we’ve accomplished in preparing this new home for the X-59,” said Bryan Watters, the NASA project manager at Armstrong who led the renovation effort. “The fact we could take a 1960s hangar and modernize it for use by a 2020’s X-plane is very special.”
The X-59 is the centerpiece of NASA’s Quesst mission to enable a new era of commercial supersonic air travel over land by reducing the sound of typically loud sonic booms to a much quieter sonic thump.
When NASA test pilot Nils Larson successfully took the X-59 into the air for the first time on Oct. 28, 2025, he flew from the Lockheed Martin Skunk Works assembly site in Palmdale to nearby NASA Armstrong, from where test flights have continued to make progress.
From the beginning of the program, knowing the X-59 would eventually need a new residence at NASA Armstrong, Quesst managers were on the hunt for somewhere to house the quiet supersonic demonstrator.
Like anyone looking for the ideal place to call home, the team made sure there would be enough space for the airplane and all its support equipment. But with the experimental jet measuring at just under 100 feet long and 30 feet wide, there were few options.
“We had to find a hangar that was long enough so that part of the X-59 wouldn’t hang outside, exposed to the elements,” Watters said.
Building 4826, as the hangar is officially designated, turned out to be the choice spot. “It was basically stripped down and gutted so that essentially it was just structural steel with siding. From that state it was rebuilt,” Watters said.
The feature they are perhaps most proud of is the hangar’s new floor. Covering more than 32,000 square feet, it is coated with epoxy that prevents any spills from seeping into the concrete.
From the hangar’s office windows, the view of the hangar floor can include the F-15 research jets that will be used as chase planes to support X-59 flights in the coming months. The renovation faced challenges along the way, chief among them being supply chain issues stemming from the COVID-19 pandemic. But there were some incredible, unforgettable moments too.
past and present
With X-59 now flying regularly and comfortably settled into its new digs, the Quesst team is gauging its performance on the way to quiet supersonic flight.
“This is truly a great time for Quesst and the X-59,” said Cathy Bahm, NASA’s project manager for the Low Boom Flight Demonstrator. “It’s also still a little surreal to be able to just walk down from your office and see the airplane in our hangar.”
For more than a year, the hangar refurbishment team worked through every detail of the X-59’s new home to make sure it would be safe and sound. But actually seeing the aircraft occupy that space is an adjustment for them, too.
“We’ve looked at X-59 models on our desk for years and then, you know, there’s the real thing right in front of us, in a hangar that we renovated,” Watters said.
A real thing in the hangar – and streaking across the California desert sky. The X-59’s transition from an idea into a working aircraft is a testament to the teams that help build out every aspect of its infrastructure.
NASA’s X-59 is supported under the agency’s Aeronautics Research Mission Directorate.
Jim Banke is a veteran aviation and aerospace communicator with more than 40 years of experience as a writer, producer, consultant, and project manager based at Cape Canaveral, Florida. He is part of NASA Aeronautics' Strategic Communications Team and is Managing Editor for the Aeronautics topic on nasa.gov. In 2007 he was recognized with a Distinguished Public Service Medal, NASA's highest honor for a non-government employee.
this scripts is long, confused and full of notes, links and questions, if you have the coffee on, it is better to stop it. This work was hard and we hope you like it.
We are talking about malware, offensive security and the attempt to legalize this institutional malware.
As we like to touch with our hands the stuff about what we talk about, we got one of this "malware" and we start do create a documentation about the setup of this. For everybody who wants to get hands dirty with us.
Then we get infected voluntarily using a device with his malware in order to study it closer, understanding how it works and which bugs may have.
Last, as many and many people are trying to create some rule and law about this very dangerous stuff we need strong guarantees in order to not accused of some false data gathered from our devices1, we have tried to generate some fake proof in order to understand how reliable are this gov-malware.
The conclusion we got is that there is no way to be sure technically that the evidence are real
We documented all the steps in a detail post, here instead, we want to analyze the ongoing proposal to legalize this malwares.
the concrete threat about the abuse of this very powerful tool move us to bring some lights on this foggy situation.
We are not law maker, but seems the malware in italy are already regulated. The crime is well now for hacker like us, 615-ter C.P. aka "Abusive Access into a System device" which shows also a specific part if the crime is done by an official.
But, the fact this tools are daily used from the police as investigation tool and nobody is showing any problem about that, is the demonstration about how a law is a perfect repressive tools, but is not working very well as justice and social tool. Which Police station will investigate about their own investigation tools ?
What we are trying to do for the future is to try to avoid that our (and yours) devices will spy us. Then, We would like spread some good security pratice in order to avoid to get infected from this and other trojans: we will surely need help because we know that won't be not exactly easy.
how do you explain the use of a tank ? We just need to talk about terrorism, about pedoporn? We just need to talk shit about some politician? Or maybe act against some big national operation ? We feel absolutely NOT protected from the italian law to regulate malware written and showed by "Civici Innovatori" (law:Quintarelli) which show a lot of issues; we just stopped a second reading tecnical operative law proposal2 how to rule and limit this and we discover they are trying to create similitudes with the malware functionality and the some regulated police pratice, like: tag after someone, intercept location data or real confiscation of the data into a device.
Trying to create similitudes between classic pratice and malware features it's absurd from every point of view and for every kind of justice act you may consider:
compare a confiscation to a remote file acquisition of a device is ridiculous. During a confiscation there's the presence of the person investigated which can verify what is happening, can request the presence of a lawyer and at the end should receive a list of the confiscated material. We can't imagine how this can be possible during a remote confiscation using a malware.
a real confiscation aim to cut off the availability of a specific tool, like a gun. The malware doesn't cut off this availability, because is not made for this.
Compare the GPS tracking of a real tagging is ridiculous. Get the digital data and easy to be analyzed from invasive algorithm is not comparable to a real shadowing, the quality of the data is completely another level.
But most of all there's a quantitative question about costs: do a shadowing from the police desk to 1000 people doesn't have the same cost to do it for real, it's clear that if yesterday doing a shadowing was a matter of time and money, but now, with a malware all you need is just to focus clic and press a button. The consequences of this is quite obvious. Just trying to imagine that this two operations are the same is quite ridiculous.
Then we start from the idea that a device is owned by the person investigated, but this is not always true. For example all the "public" device, the internet point, the libraries, the university. Reading the email from an internet point tapped where a person under surveillance used the pc before of us, bring us a risk because the pc is bugged (so is an infected pc) our email will go to the police. Even if we with a used device, our email will be delivered to the police.
Then there is a temporal problem. With a classical mobile interception, the SMS are grabbed starting from a specific day and the interception has a time limit for legal reason. The trojan is another story, it can read the data with no time limit, sending all the conversation on the device from the beginning of it's history, because it is all saved there.
During a shadowing there's the guarantee (except to hire a lookalike) that the position is the effective location of the investigated person. But the device may not travel with the person, it can be stolen or forgotten in a taxi. So basically the device owned by the person is not the person.
To believe as we read in the document, that the installation of a malware doesn't lower the security level where is installed is ridiculous, the base idea of the malware is exactly to let open some vulnerability in order to use it and doing so keep insecure the device of everybody in order to infect them.
To certify the impossibility to alterate the evidence seems impossible to obtain and later we prove it in two different way. But there's more. How is possible to certify the producer is not compromised? How is possible to verify that behind the massive architecture there's not a backdoor for someone else being able to use it? No, there's no way to verify it.
Lastly, seems a paradox for us that the government want to use digital weapons bought from a shadow market and very less transparent as the zero-day market
during our experiment we notice that the input of this 'objects' are considered trusted (not modified by the user), which is clearly erroneous. What may happen if a skype username is AAAA' DROP ALL TABLES--? and if it's length is 10million chars? And what if instead of an image we put something different and the malware breaks ? (yes it broke very badly). How the law will consider this social behaviour? self-defense? evidence occultation?
For us this 'objects' can't be regulated. For us there's a danger hidden into the secret action of the government over the citizen and this danger is way more unsafe than any other threats, fullstop.
We want to know all, not just the stats about how many malware are sold or exported (as recently requested by Hermes to the italian government), but we want to know specifically how exactly are used these new surveillance technique, like IMSI-Catcher or Government Malware and how many of them are used
If someone want to tell us, fell free to write us an email:
Underscore _TO* Hacklab // underscore chiocciola autistici.org
Key fingerprint = 5DAC 477D 5441 B7A1 5ACB F680 BBEB 4DD3 9AC6 CCA9
gpg2 --recv-keys 0x9AC6CCA9
questo scritto è lungo, confuso e denso di appunti, link e domande, se avete il caffè sul fuoco,
toglietelo. è stato un lavoro sudato, speriamo vi piaccia.
parliamo di captatori informatici, sicurezza offensiva e il tentativo di normare questi trojan di stato.
siccome ci piace toccare con mano gli oggetti dei nostri ragionamenti, ci siamo procurati uno di questi "captatori informatici" e ne abbiamo documentato il setup completo per chi volesse sporcarsi le mani con noi (grazie al lab61 per averci messo la pulce nell'orecchio).
successivamente abbiamo infettato volontariamente un dispositivo con il malware per vederne il funzionamento da vicino, quali funzionalità presenta e quali difetti.
in ultimo, dal momento che nel tentativo di normare questi pericolosi strumenti leggiamo della "necessità di forti garanzie per essere inattacabile sul piano della veridicità dei dati acquisiti", abbiamo provato a generare delle prove non valide per capire quanto sono affidabili questi malware (non contenti l'abbiamo fatto in due modi diversi).
la conclusione a cui siamo arrivati è che no, non esiste modo di garantire tecnicamente che le prove raccolte siano veritiere.
abbiamo anche fatto un'analisi tecnica della proposta di legge sottolineandone le criticità qui.
(legenda: le parti a sfondo bianco come questa sono per tutti i lettori, quelle a sfondo nero sono più tecniche e interessanti per qualcuno, noiose per qualcun altro, vi assicuriamo che saltarle non pregiudicherà la lettura).
installare galileo
un piccolo disclaimer: vi potete fare male, noi non abbiamo mai fatto uscire nessuna delle installazioni su internet liberamente, suggeriamo di fare lo stesso.
siamo partiti da questo link, un tutorial per il setup, modificando alcuni passaggi. in particolare abbiamo eliminato vari check della licenza per cui non è più necessario cambiare la data del sistema (molto scomodo su una macchina virtuale) ed è ora quindi possibile abilitare tutte le funzionalità.il setup minimo necessita almeno di 4 macchine:
- un master (windows 7, almeno 4Gb di ram)
- un collector (windows 7, almeno 1Gb di ram)
- un anonymizer (suggerito centos solo cli, anche solo 300mb di ram, io ho usato un container con alpine via runc)
- un target (fate voi, una debian, un android, un mac)
se volete strafare, servirá anche una macchina che faccia da network tactical injector, cioè l'oggetto usato per infettare le vittime attraverso attacchi wifi.
le prime due voci le abbiamo installate in macchine virtuali su un portatile con 8Gb di ram usando virtualbox, ma se avete delle macchine da sacrificare è uguale.
per iniziare guardiamo uno schema di come funziona l'architettura:
ora decidiamo gli ip statici per ogni macchina:
master: 192.168.56.2
collector: 192.168.56.3
anonymizer: 192.168.56.4master
- installo Windows 7 su una VM e imposto come ip dell'interfaccia
192.168.56.2- installo rcs-setup-2015032102.exe
- installo rcs-exploits-2015032101.exe
- seleziono Master Node
- in CN metto
192.168.56.2: questo ip verra' usato anche come CN del certificato https, potevo anche usare un nome ma poi toccava editare/etc/hostsdi windows- metto la password con cui controllerò tutto:
RCSMaster1- metto la licenza e a questo punto parte l'installazione.
- quando vedo "Remove previous master node files" sostituisco questo file in C:\RCS\bin\
- siccome ad ogni avvio ricontrolla la licenza, finita l'installazione devo sostituire anche questo file in C:\RCS\DB\lib\
- ora installo anche Adobe Air e la console
- a questo punto riavvio la macchina o i servizi e apro la console
- inserisco la loro CA come trusted dentro l'albero delle root CA
- inserisco le credenziali, vado dentro
monitore passo ad installare il collectorcollector
- come sopra ma scelgo Collector invece di Master Node
- imposto l'ip come scelto in precedenza per il collector, quindi
192.168.56.3- il common name del master richiesto sará quindi
192.168.56.2- torno sul master
master #2
- dentro
Systemdella console dovrebbe a questo punto comparire un collector- faccio un nuovo anonymizer a cui assegno come ip
192.168.56.4collego l'anonymizer al collettore
creo il pacchetto per l'anonymizer premendo
Download installeranonymizer
- preparo una macchina per installare l'anonymizer (consigliano una centos)
- io ho usato un container (runc) a cui ho dato come ip
192.168.56.4- prendo lo .zip creato sopra e installo l'anonymizer (bbproxy, lo mette dentro /opt)
- quando tutto funziona, in
Systemdella console vediamo questo:a questo punto siamo pronti per studiare, ecco i manuali di riferimento:
dopo aver installato e letto i manuali d'uso di RCS, abbiamo voluto provare effettivamente cosa è in grado di fare questo captatore informatico.
abbiamo quindi volontariamente infettato una nostra macchina linux e testato il funzionamento del tutto.
per prima cosa apriamo un'indagine (Operations->New Operation) a cui aggiungiamo un indagato sul cui ipotetico computer d'ufficio vogliamo installare un agente:
ora con una facile interfaccia punta e clicca possiamo selezionare le funzionalità del trojan da attivare
se invece vogliamo una configurazione particolare, come ad esempio limitare l'uso della batteria dell'agente possiamo utilizzare la modalità avanzata:
qui sopra un esempio di come è possibile attivare determinati moduli solamente quando il dispositivo è in carica.
per completezza ecco l'elenco dei possibili eventi, delle possibili azioni e di tutti i moduli.
se volete studiare tutte le funzionalità, rimandiamo alla documentazione ufficiale.
ovviamente non tutte le funzionalità sono compatibili con tutti i sistemi operativi, per avere una lista delle compatibilità vi rimandiamo anche in questo caso alla documentazione ufficiale e a quella non ufficiale.
quando la configurazione ci soddisfa, procediamo con la creazione del vero e proprio agente
premendo in alto a sinistra su Build.
ora manca solo di scegliere come infettare la vittima:
i vettori di infezione sono tanti, anche in questo caso la documentazione ufficiale ci viene in aiuto. la scelta del vettore da usare dipende in gran parte dalla vicinanza del dispositivo da infettare:
avendo accesso fisico al dispositivo (ad esempio in aereoporto, durante un controllo o una perquisizione) è possibile installare il malware via:
se è possibile avvicinare la vittima (facendo ad esempio un appostamento fuori dall'abitazione) è possibile introdursi nella sua rete wireless o emularla attraverso una serie di attacchi usando quello che viene chiamato il Tactical Network Injector.
noi purtroppo non abbiamo la possibilità di provare direttamente da un ISP l'installazione del Network Injector e avendo accesso fisico al dispositivo del fittizio indagato, ci infettiamo volontariamente con un Silent Installer per linux.
l'infezione
pubblichiamo l'agente venuto fuori dalla build per chi volesse sporcarsi le mani, SE NON SAPETE COSA STATE FACENDO, NON FATELO, SUL SERIO
NON SCARICARMI SE NON DEVI.zip
ovviamente non ci sarebbe bisogno di fare reverse engineering visto che abbiamo i sorgenti, ma siccome se non vediamo non crediamo, lo faremo ugualmente, non prima di vederlo in azione però. se avete linux e avete paura di essere infetti da un paio d'anni e non potete aspettare, date un'occhio dentro
~/.config/autostart/.*,/var/crash/.report*e/var/tmp/.report*ma non sperate di trovare qualcosa perchè nelle licenze italiane le funzionalità per infettare linux non sono state comprate.
ps. abbiamo ascoltato il traffico con wireshark ma sembra che non cerchi di andare altrove.
attendiamo 5 minuti che l'agente raccolga i dati e ce li invii ed ecco i primi risultati in una comoda dashboard:
vediamo ora una carrellata delle possibilità, possiamo navigare il file system della vittima
possiamo inserire file, eseguirli e ovviamente scaricarli
possiamo inviare comandi e riceverne i risultati
e poi ovviamente guardare tutte le prove, quindi screenshoot (con supporto OCR)
un simpatico keylogger e tutti gli eventi del mouse
le foto dalla webcam con la frequenza scelta
la lista dei siti visitati
le password salvate da firefox e chrome
ovviamente con la possibilità di filtrare il materiale con filtri di tutto rispetto
ci fermiamo qui anche se ci sarebbero tanti altri moduli da provare, i messaggi, i contatti, i wallet bitcoin, l'infezione di un'android, il network tactical injector, gli exploits....
ok, l'abbiamo installato e provato per poterlo analizzare meglio
e farci la seguente domanda: ma quanto sono sicuri questi captatori informatici?
sono veramente dei generatori di prove affidabili e veritiere come si vorrebbe sostenere?
come raccolgono le prove? proviamo ad immaginare come potremmo fare noi, prendendo a titolo di esempio i contatti skype:
i contatti skype sono presenti nel computer dentro un file
contentente una base dati.
questa base dati non è protetta
in nessun modo, ed è direttamente accessibile da chiunque,
sia da Skype che da un qualsiasi altro programma e ovviamente
anche dai captatori informatici, che vanno a cercare dentro
quella base dati la lista dei contatti e la nostra messaggistica.
dove si trova di preciso? la base dati di skype su linux si trova dentro ~/.Skype/<profiloutente>/main.db
proviamo allora a creare da noi questa base dati senza neanche avere skype installato sul computer e inserire dei contatti fittizi al suo interno. funzionerà?
falsi contatti
la base dati in questione è un sqlite, il cui schema è reperibile pubblicamente. creiamo quindi dentro la macchina della vittima una directory per ospitare il nostro finto profilo skype al cui interno inseriamo il nostro db sqlite compatibile con lo schema skype:
mkdir -p ~/.Skype/fakeprofile/ sqlite3 ~/.Skype/fakeprofile/main.db # creo i db 'Accounts' e 'Contacts' # https://github.com/suurjaak/Skyperious/blob/master/skyperious/skypedata.py#L128 # creo un account INSERT INTO Accounts (skypename, fullname, is_permanent) VALUES ('account falso', 'account falso', 1); # inserisco dei contatti a piacimento INSERT INTO Contacts (skypename, displayname, birthday, is_permanent) VALUES("contatto falso", "contatto falso",0,1); .quit
a questo punto attendiamo che il captatore raccolga le nuove prove e ....
per i siti visitati attraverso chrome/firefox e altri browser vale lo stesso discorso, perchè questi vengono salvati all'interno di una base dati simile a quella usata da skype.
anche per il microfono, la webcam, gli screenshoot del monitor e in generale per ogni tipo di dato acquisito, non solo è difficile se non impossibile dire con certezza se i dati carpiti all'insaputa dell'utente siano veritieri o meno, ma è anche relativamente semplice falsificare questi dati da parte di terzi (pensiamo ad un'applicazione su android ad esempio).
è possibile evitarlo? no.
ma quanto sono sicuri questi captatori informatici? nel proseguire il nostro studio sull'argomento, vogliamo sottolineare una questione secondo noi importante. non divulgare le falle di sicurezza dei nostri dispositivi per avere la possibilità di poterli infettare mantiene inevitabilmente meno sicuri i dispositivi di tutti, compresi quelli di chi i captatori informatici li utilizza.
abbiamo visto come sia possibile falsificare le prove prima che vengano raccolte, cerchiamo ora di capire come funziona l'invio dei dati raccolti in RCS e vediamo se è possibile inviare delle prove create ad-hoc.
reverse engeenering
ed eccoci alla parte più interessante del nostro studio (nonchè la più divertente). la descrizione del reverse engeenering che segue è molto piu' lineare di come si è svolta nella realtà, abbiamo saltato le parti noiose e ripetitive (openssl l'abbiamo ricompilato almeno 6 volte) e cercato inoltre di rendere i ragionamenti sequenziali, quando nella realtà tante scelte sono state fatte intuitivamente. siamo inoltre convinti che si poteva ottenere lo stesso risultato in altri N modi e che quello da noi usato è sicuramente molto grezzo.
innanzitutto, ipotizziamo di avere solo il binario, il malware. dobbiamo capire cosa fa e come si comporta. creiamo quindi un ambiente di studio, un container che lo isoli in un posto sicuro dove non puo' fare danni e in cui è possibile studiarne il comportamento.
noi abbiamo usato runc usando come rootfs una debian dentro una directory montata con loggedfs per controllare tutti i suoi movimenti sul file system (file creati, letti, etc...).
vediamo subito che si installa dentro/var/crash/.report*/whoopsie-reporte cerchiamo di capire di che file si tratta con un:$ file whoopsie-report whoopsie-report: ELF 64-bit LSB executable, x86-64, version 1 (GNU/Linux), statically linked, stripped`è un piccolo file statico di 77kb, un po' troppo piccolo per essere veramente statico, lo avviamo con
strace ./whoopsie-reporte notiamo infatti che cerca di aprire parecchie librerie di sistema, tra cui:
- /lib/x86_64-linux-gnu/libpthread.so.0
- /lib/x86_64-linux-gnu/libc.so.6
- /usr/lib/x86_64-linux-gnu/libcurl-gnutls.so.4
- /usr/lib/x86_64-linux-gnu/libcrypto.so.1.0.0
- /usr/lib/x86_64-linux-gnu/libX11.so.6
e qui gia' ci sarebbe spazio per divertirsi: libX11 viene sicuramente utilizzata per fare gli screenshot dello schermo, sarebbe possibile ricompilarla per fare in modo che per alcuni programmi dei metodi tornino cose inaspettate.
ad un certo punto notiamo che vengono creati dei files dentro
/var/crash/.report*/.tmp*, sono presumibilmente le prove raccolte, anche perchè ciclicamente si moltiplicano.all'interno solo dati binari, controlliamo se sono solamente compressi, ma non ci sembra, saranno cifrati? ma come? per una cosa del genere a noi verrebbe da utilizzare le librerie standard, quindi
openssl, ma come possiamo esserne sicuri? in effetti il malware accede alibssl.
perdiamo un po' di tempo provando congdbma stufi di seguire tutti i thread, ci viene in mente di ricompilare libssl inserendo del debug che ci mostri come vengono cifrati i dati.per ricompilare un pacchetto debian seguiamo questa guida, ci armiamo di pazienza e scarichiamo il tutto.
cercando come si cifra con openssl vediamo che ci sono parecchie chiamate differenti, quindi proviamo conltrace(con strace si vedono le syscall, con ltrace le libcall) a vedere se possiamo capire quale chiamata viene usata:$ ltrace ./whoopsie-report Couldn't find .dynsym or .dynstr in "/proc/30234/exe"questo e' parecchio strano ma smanettando un po' troviamo con
stringsla seguente stringa dentro il malware:$ strings ./whoopsie-report $Info: This file is packed with the UPX executable packer http://upx.sf.net $leggiamo che upx è un packer che comprime binari, installiamo quindi
upx-ucle proviamo unupx-ucl -d whoopsie-reportper fare il processo inverso e decomprimere il binario:File size Ratio Format Name -------------------- ------ ----------- ----------- 261044 <- 77972 29.87% linux/ElfAMD whoopsie-reportora abbiamo il binario "in chiaro" e riprovando con ltrace (qui siamo passati dentro una macchina virtuale con VirtualBox perchè dentro runc si bloccava per qualche motivo) otteniamo le chiamate usate dal malware, in particolare nel nostro interesse ricadono le seguenti:
dlsym(0x122f4c0, "EVP_get_cipherbyname")dlsym(0x122f4c0, "BIO_set_cipher")a questo punto cerchiamo quei metodi nei sorgenti di libssl e troviamo la prima chiamata in
crypto/evp/names.clinea 112 a cui aggiungiamo questo debug che scrive il cifrario usato dentro un fileconst EVP_CIPHER *EVP_get_cipherbyname(const char *name) { const EVP_CIPHER *cp; // DEBUG: scrivo il cifrario utilizzato dentro un file FILE *f; f = fopen("/tmp/debug_ciphername", "w"); // <- qui trovo il cifrario fprintf(f, "%s", name); fclose(f); cp = (const EVP_CIPHER *)OBJ_NAME_get(name, OBJ_NAME_TYPE_CIPHER_METH); return (cp); }e la seconda chiamata in
crypto/evp/bio_enc.ce anche qui aggiungiamo del debug:void BIO_set_cipher(BIO *b, const EVP_CIPHER *c, const unsigned char *k, const unsigned char *i, int e) { BIO_ENC_CTX *ctx; // DEBUG: scrivo i parametri del cifrario su file FILE *f; f = fopen("/tmp/debug_cipher", "a+"); fprintf(f, "\n----\n"); fprintf(f, "block_size: %d, key_len: %d, iv_len: %d\nkey: ", c->block_size, c->key_len, c->iv_len); for(int co=0; co<c->key_len; co++) { fprintf(f, "%02X",k[co]); } fprintf(f,"\n\niv: "); for(int co=0; co<c->iv_len; co++) { fprintf(f, "%02X", i[co]); } fprintf(f,"\n\n"); fclose(f); ....ricompiliamo le librerie, installiamo e rilanciamo il malware. dentro
/tmptroviamo ora il cifrario usato dal malware e la chiave:$ cat /tmp/debug_ciphername aes-128-cbc $ cat /tmp/debug_cipher ---- block_size: 16, key_len: 16, iv_len: 16 key: 692CC9D0DC834E4663EF389470E445B4 iv: 00000000000000000000000000000000(= a questo punto proviamo a decifrare i file salvati su disco dal malware, lo scopo è ovviamente tentare di scriverne noi uno ad-hoc, con la chiave a disposizione dovrebbe essere facile, invece perdiamo un sacco di tempo a capire come mai non riusciamo a decifrare la prima parte del file. pensavamo fosse legato al vettore di inizializzazione e invece nel file c'e' un header di qualche tipo, ovvero il blocco cifrato non comincia all'inizio (questo però ovviamente openssl non lo dice). il punto è che la lunghezza del testo cifrato ogni tanto non è un multiplo del BLOCK_SIZE del cifrario a blocchi usato, il che significa che c'è qualcosa che non dovrebbe esserci. abbiamo provato prima manualmente ad eliminare un po' di bytes prima di tentare il decrypt ed effettivamente ha funzionato:
#!/usr/bin/python from Crypto.Cipher import AES import sys key = "692cc9d0dc834e4663ef389470e445b4" IV = "00000000000000000000000000000000" encrypted = open(sys.argv[1]).read() x = 16 - len(encrypted)%16 if len(encrypted)%16 else 0 x += 16*int(sys.argv[2]) encrypted = encrypted[x:] aes = AES.new(key.decode('hex'), AES.MODE_CBC, IV.decode('hex')) print aes.decrypt(encrypted) $ chmod +x test.py $ ./test.py .tmp-1491179387-220638-SJBo7P 10 > image.jpgil file in questione (il .tmp-149..) è stato selezionato perchè dalle dimensioni poteva sembrare un'immagine, inoltre decifrandolo inizialmente c'erano stringhe che riconducevano al formato JPG (ma non trovavamo il magic byte DD F8!). quel 10 invece indica che prima dell'inizio dell'immagine all'interno del file salvato su disco, ci sono ben 160 bytes di header. il prossimo passo è cercare di scrivere noi l'immagine dentro uno dei file, quindi apriamo con
gimpl'immagine estratta in precedenza (quindi con il vero screenshot) in modo da mantenerne le proprietà (colori, dimensioni, ecc.) e sostituirla dentro il file di cui sopra.#!/usr/bin/python from Crypto.Cipher import AES import sys key = "692cc9d0dc834e4663ef389470e445b4" IV = "00000000000000000000000000000000" original_header = open(sys.argv[1]).read()[:168] new_image = open('.tmp-1491179387-220638-SJBo7P','w') # mantengo l'header come era prima senza indagare oltre new_image.write(original_header) fake_image = open(sys.argv[2]).read() # padding x = 16 - len(fake_image)%16 if len(fake_image)%16 else 0 fake_image += x*"\0" # cifro l'immagine fake e la scrivo sul nuovo file aes = AES.new(key.decode('hex'), AES.MODE_CBC, IV.decode('hex')) new_image.write(aes.encrypt(fake_image)) new_image.close()
ora basta solo aspettare e....
Underscore _TO* Hacklab // underscore chiocciola autistici.org
Key fingerprint = 5DAC 477D 5441 B7A1 5ACB F680 BBEB 4DD3 9AC6 CCA9
gpg2 --recv-keys 0x9AC6CCA9
https://autistici.org/underscore
questo scritto è lungo, confuso e denso di appunti, link e domande, se avete il caffè sul fuoco, toglietelo. è stato un lavoro sudato, speriamo vi piaccia.
parliamo di captatori informatici, sicurezza offensiva e il tentativo di normare questi trojan di stato.
siccome ci piace toccare con mano gli oggetti dei nostri ragionamenti, ci siamo procurati uno di questi "captatori informatici" e ne abbiamo documentato il setup per chi volesse sporcarsi le mani con noi.
successivamente abbiamo volontariamente infettato un dispositivo con il malware per vederne il funzionamento da vicino, quali funzionalità presenta e quali difetti.
in ultimo, dal momento che nel tentativo di normare questi pericolosi strumenti leggiamo della "necessità di forti garanzie per essere inattacabile sul piano della veridicità dei dati acquisiti", abbiamo provato a generare delle prove non valide per capire quanto sono affidabili questi captatori.
la conclusione a cui siamo giunti è che non esiste modo di garantire tecnicamente che le prove raccolte siano veritiere.
abbiamo documentato tutto in questo dettagliato post, qui invece ci proponiamo di fare un'analisi alle proposte di normare questi captatori informatici.
la concreta minaccia dell'abuso di questo potente strumento ci muove a far luce su questa fumosa questione.
non siamo giuristi ma ci sembra che i captatori informatici siano già normati, il reato lo conosciamo bene noi acari, il 615-ter c.p. "accesso abusivo ad un sistema informatico" che presenta anche un comma specifico se il reato è commesso da un pubblico ufficiale. il fatto che questi strumenti siano, però, quotidianamente usati dalle forze di polizia come strumento di indagine e che nessuno stia storcendo il naso per questo, è la dimostrazione di come la legge sia un'ottimo strumento repressivo ma non funzioni un granchè come strumento di giustizia sociale. quale procura potrebbe indagare sui suoi stessi strumenti di indagine?
quello che ci proponiamo di fare per il futuro è cercare di evitare che i nostri (e i vostri) dispositivi ci spiino. vogliamo inoltre diffondere delle buone pratiche di sicurezza per evitare di farsi infettare da questi e altri trojan: avremo sicuramente bisogno di aiuto perchè sappiamo che non sarà affatto semplice.
come si giustifica l'uso di un carro armato? basta parlare di terrorismo, di pedofilia? è sufficiente parlare male di un parlamentare? o magari opporsi alla costruzione di una grande opera? non ci sentiamo per niente tutelati dal decreto di legge presentato dai civici e innovatori (ddl quintarelli) dalla quale emergono moltissime criticità; ci siamo soffermati sulla "disciplinare tecnico operativa"
la tesi di fondo del documento è quella di fare un paragone tra le funzionalità del captatore e le corrispondenti azioni di polizia giudiziaria già attualmente normate, per esempio paragonando pedinamento reale e intercettazione dati di posizionamento, o sequestro reale con acquisizione file da dispositivo.
l'equiparazione tra le modalità classiche e quelle implementate dal captatore ci sembra assurdo da ogni punto di vista e per qualunque tipologia di azione giudiziaria considerata:
paragonare un sequestro all'acquisizione remota di file sul dispositivo è ridicolo. durante un sequestro c'è la presenza dell'indagato che può verificare quello che accade, può richiedere la presenza di un legale e gli viene rilasciata una lista del materiale sequestrato. non riusciamo ad immaginarci come questo sia possibile tramite un sequestro da remoto tramite captatore.
il sequestro reale è teso a togliere la disponibilità di un oggetto, una pistola ad esempio. il captatore non toglie la disponibilità dell'oggetto del sequestro, perchè non è quello il suo scopo.
paragonare il tracciamento gps ad un pedinamento è ridicolo. avere i dati digitalizzati e facilmente analizzabili da algoritmi invasivi non è paragonabile ad un pedinamento, la qualità del dato è proprio di un altro livello.
ma soprattutto c'è una questione quantitativa e di costi: fare un pedinamento dalle scrivanie della questura verso 1000 persone non ha lo stesso costo che farlo per davvero, è evidente che se fino a ieri pedinare gli indagati richiedeva un certo dispiegamento di forze e denaro, con l'utilizzo di un captatore il tutto si riduce a premere qualche tasto su un'interfaccia punta e clicca. la conseguenza di questo è abbastanza ovvia. immaginare l'equivalenza delle due situazioni è ridicolo.
si parte poi dal presupposto che un dispositivo sia di un indagato, mentre non è sempre vero. prendiamo come esempio tutti i dispositivi "pubblici", gli internet point, le biblioteche, le università. leggendo le mail da un internet point usato da un indagato prima di noi (e quindi su un computer infetto) le stesse finirebbero in questura. comprando un dispositivo usato, le nostre mail finirebbero in questura.
c'è inoltre un problema temporale. all'avvio di un'intercettazione telefonica classica, gli sms intercettati partono appunto da un giorno e l'intercettazione ha poi un limite di tempo per ovvi motivi. il trojan invece può leggere i dati senza limiti temporali, inviando tutte le conversazioni avvenute sul tuo dispositivo dall'inizio dei tempi (perchè sono tutte salvate lì).
durante un pedinamento c'è la garanzia (a meno di assumere un sosia?) che la posizione sia quella effettiva dell'indagato. il dispositivo invece potrebbe non viaggiare con l'indagato, potrebbe essere stato rubato o potrebbe essere stato lasciato sul sedile di un taxi. insomma il dispositivo dell'indagato non è l'indagato.
credere, come si legge nel documento, che l'installazione di un captatore non abbassi il livello di sicurezza dei dispositivi su cui è installato è ridicolo, l'idea del captatore si basa proprio sul fatto di lasciare aperte delle falle di sicurezza e quindi di mantenere appositamente insicuri i dispositivi di tutti, per avere la possibilità di poterli infettare.
certificare la non modificabilità delle prove acquisite ci sembra impossibile da ottenere e l'abbiamo provato in due modi diversi. inoltre come è possibile certificare che il produttore non sia stato compromesso? come è possibile certificare che nella imponente architettura non ci sia una backdoor? no, non è possibile farlo.
e ancora, ci sembra paradossale che lo stato utilizzi armi digitali acquistate su un mercato opaco e poco trasparente come quello degli zero day.
durante gli esperimenti abbiamo notato che gli input di questi oggetti vengono considerati trusted (cioè non modificabili dall'utente), cosa ovviamente non vera. cosa succede se un contatto skype si chiama AAAA' DROP ALL TABLES--? e se è lungo 10mila caratteri? e se al posto di un'immagine mettiamo qualcosa di altro e il captatore si rompe? (si, si rompe male). come la legge vedrebbe un comportamento simile? legittima difesa? occultamento di prove?
per noi questi oggetti non sono normabili. per noi c'è un pericolo insito nell'azione segreta
di una parte dell'apparato dello stato sul cittadino e questo pericolo sovrasta ogni altro
pericolo.
punto.
vogliamo sapere non solo le statistiche di esportazione di questi strumenti (come richiesto di recente dal centro hermes al ministero dello sviluppo economico), ma soprattutto come e quanto vengono utilizzate in italia oggi queste tecnologie di sorveglianza, che si chiamino imsi catcher o trojan di stato. se qualcuno vuole comunicarcelo, ci scriva una mail.
Underscore _TO* Hacklab // underscore chiocciola autistici.org
Key fingerprint = 5DAC 477D 5441 B7A1 5ACB F680 BBEB 4DD3 9AC6 CCA9
gpg2 --recv-keys 0x9AC6CCA9
Accedi
