Nell’era dell’informazione, la cybersecurity si erge a baluardo contro minacce digitali in continua evoluzione. Tuttavia, le difese più sofisticate possono vacillare di fronte a un nemico invisibile e insidioso: i bias cognitivi che plasmano il nostro processo decisionale. Tra questi, il bias di ancoraggio emerge come un fattore critico, influenzando silenziosamente le valutazioni di rischio, le risposte agli incidenti e persino l’adozione di misure protettive. Comprendere la profonda connessione tra cybersecurity e questo meccanismo psicologico è fondamentale per rafforzare le nostre difese e navigare con maggiore consapevolezza il complesso panorama digitale.

Le manifestazioni del Bias di ancoraggio

Il bias di ancoraggio ci porta a fare eccessivo affidamento sulla prima informazione disponibile quando prendiamo decisioni in condizioni di incertezza. Questa “àncora” iniziale, anche se irrilevante o incompleta, influenza in modo sproporzionato i nostri giudizi successivi.

Nel contesto della cybersecurity, questo si traduce in una serie di vulnerabilità cognitive che i cybercriminali possono astutamente sfruttare:

• Valutazione del Rischio: Un analista di sicurezza potrebbe ancorare la propria valutazione del rischio di un nuovo attacco a statistiche obsolete o a un incidente passato specifico, sottovalutando la potenziale portata o sofisticazione della minaccia attuale. L’àncora del “già visto” impedisce una valutazione fresca e completa.
• Analisi delle Vulnerabilità: Un team di sicurezza potrebbe concentrarsi eccessivamente sulla prima vulnerabilità critica identificata da uno scanner automatico, ancorando a quel “punteggio alto” la propria priorità di intervento, trascurando vulnerabilità meno evidenti ma potenzialmente più sfruttabili in combinazione.
• Risposta agli Incidenti: Durante un attacco, le prime informazioni frammentarie sulla sua origine o sul vettore iniziale potrebbero ancorare le indagini del team di risposta, portandoli a focalizzarsi su una pista errata e ritardando l’identificazione della vera causa e la mitigazione efficace.
• Scelta di Soluzioni di Sicurezza: Il prezzo iniziale di una soluzione di sicurezza o la prima funzionalità accattivante presentata da un venditore possono agire come ancore potenti, influenzando la percezione del valore complessivo e oscurando la valutazione di alternative potenzialmente più adatte o di considerazioni a lungo termine.
• Comportamento degli Utenti: Gli utenti finali possono ancorare la propria fiducia a elementi superficiali come un logo familiare in un’email di phishing o un tono rassicurante, ignorando segnali d’allarme più sottili e cadendo vittime di attacchi di social engineering.

Le Tattiche dei Cybercriminali

I cybercriminali, spesso senza una formale formazione in psicologia, dimostrano una sorprendente intuizione nel manipolare il bias di ancoraggio a proprio vantaggio. Le loro tattiche sono finemente calibrate per sfruttare la nostra tendenza ad affidarci alla prima informazione ricevuta. Un’email di phishing che imita alla perfezione la grafica e il tono della nostra banca crea un’ancora di familiarità e fiducia, rendendoci meno inclini a scrutinare attentamente il contenuto. Un messaggio allarmante che annuncia un’urgente violazione della sicurezza del nostro account innesca un’ancora emotiva di paura e ansia, spingendoci ad agire impulsivamente senza riflettere. Offerte online incredibilmente vantaggiose ancorano la nostra attenzione sul guadagno potenziale, distraendoci dai segnali d’allarme di una possibile truffa.

In sostanza, i criminali informatici gettano queste “ancore” psicologiche nel flusso delle nostre interazioni digitali, sapendo che la nostra mente, una volta agganciata, sarà più facilmente guidata verso azioni che compromettono la nostra sicurezza.

La Vera Vulnerabilità

In un’era in cui le minacce informatiche si evolvono con rapidità sorprendente, affidarsi unicamente a soluzioni tecnologiche per la difesa è come costruire una fortezza con fondamenta instabili. Il bias di ancoraggio ci svela una verità fondamentale: le vulnerabilità più pericolose non risiedono sempre nelle righe di codice, ma nelle scorciatoie mentali che adottiamo per navigare la complessità del mondo digitale.

Riconoscere il potere silenzioso di questa “prima impressione” – quel primo contatto visivo con un’email, quel titolo accattivante di un link, quell’allarme inaspettato sullo schermo – è un atto di consapevolezza cruciale, un invito a esercitare una vigilanza che trascende la mera tecnologia, abbracciando la profondità della psicologia umana.

Comprendere il bias di ancoraggio è come riconoscere la corrente insidiosa che ci spinge verso scogli digitali apparentemente sicuri; solo diventando marinai consapevoli delle sue forze invisibili potremo governare la nostra navigazione online con prudenza, evitando che la prima impressione diventi la nostra ultima, disastrosa, destinazione.

Ignorare la psicologia nella cybersecurity è come costruire un’imponente fortezza digitale dimenticando di presidiare le porte con sentinelle umane: per quanto solide siano le mura virtuali, una mente non consapevole dei bias resta una breccia aperta, un invito silenzioso per i predatori del cyberspazio.

L'articolo Pensavi di Essere al Sicuro? Il Vero Malware È Nella Tua Testa! proviene da il blog della sicurezza informatica.

Introduction

The way threat actors use post-exploitation frameworks in their attacks is a topic we frequently discuss. It’s not just about analysis of artifacts for us, though. Our company’s deep expertise means we can study these tools to implement best practices in penetration testing. This helps organizations stay one step ahead.

Being experts in systems security assessment and information security in general, we understand that a proactive approach always works better than simply responding to incidents that have already occurred. And when we say “proactive”, we imply learning new technologies and techniques that threat actors may adopt next. That is why we follow the latest research, analyze new tools, and advance our pentesting expertise.

This report describes how our pentesters are using a Mythic framework agent. The text is written for educational purposes only and intended as an aid for security professionals who are conducting penetration testing with the system owner’s consent.

It’s worth noting that Kaspersky experts assign a high priority to the detection of the tools and techniques described in this article as well as many similar others employed by threat actors in real-world attacks.

These efforts to counter malicious actors use solutions like Kaspersky Endpoint Security that utilize the technologies listed below.

• Behavioral analysis tracks processes running in the operating system, detects malicious activity, providing added security for critical OS components such as the Local Security Authority Subsystem Service process.
• Exploit prevention stops threat actors from taking advantage of vulnerabilities in installed software and the OS itself.
• Fileless threats protection detects and blocks threats that, instead of residing in the file system as traditional files, exist as scheduled tasks, WMI subscriptions, and so on.
• There are many others too.

However, it’s worth noting that since our study discusses a sophisticated attack controlled directly by a malicious actor (or a pentester), more robust defense calls for a layered approach to security. This must incorporate security tools to help SOC experts quickly detect malicious activity and respond in real time.

These include Endpoint Detection and Response, Network Detection and Response and Extended Detection and Response solutions as well as Managed Detection and Response services. They provide continuous monitoring and response to potential incidents. Usage of threat intelligence to acquire up-to-date and relevant information about attacker tactics and techniques is another cornerstone of comprehensive defense against sophisticated threats and targeted attacks.

This study is the product of our exploration and analysis: how we as defenders can best prepare and what we should expect. What follows is part one of the report in which we compare pentesting tools and choose the option that suits the objectives of our study. Part two deals with how to communicate with the chosen framework and achieve our objectives.

Pentester tools: how to choose

An overview of ready-made solutions

Selecting pentesting tools can prove a challenging task. Few pentesters can avoid detection by EPP or EDR solutions. As soon as a pentesting tool gains popularity among attackers, defensive technologies begin detecting not only its behavior, but also its individual components. Besides, the ability to detect the tool becomes a key performance indicator for these technologies. As a result, pentesters have to spend more time preparing for a project.

At the same time, many existing solutions have flaws that impede pentesting. Ethical hackers, for example, frequently use Cobalt Strike. The Beacon agent uses a specific opcode sequence in platform version 4.9.1. To avoid detection by security solutions, opcodes must be changed, but that breaks the agent.

Immutable opcode sequence for Cobalt Strike agent

Another example is Metasploit’s Meterpreter payload, whose signatures appear in Microsoft’s antivirus database more than 230 times, making the tool significantly more difficult to use in projects.

The Sliver framework is an open-source project. It is in active development, and it can handle pentesting tasks. However, this project has a number of drawbacks, too.

1. The size of a payload generated by the framework is 8–9 megabytes. This reduces flexibility because the ideal size of a pentesting agent that ensures versatility is about 100 KB.
2. Stability issues. We’ve seen active sessions drop. The framework once lacked support for automatically using a proxy server from the Windows configuration, which also complicated its use. This has since been addressed.

The Havoc framework and its Demon payload are currently gaining popularity: both are evolving, and both support evasion techniques. However, the framework currently suffers from a lack of compliance with operational security (OPSEC) principles and stability issues. Additionally, payload customization in Havoc is limited by rigid parameters.

As you can see, we cannot fully rely on open-source projects for pentesting due to their significant shortcomings. On the other hand, creating tools from scratch would require extra resources, which is inefficient. So, it’s crucial to strike the right balance between building in-house solutions and leveraging open-source projects.

Payload structure

First, let’s define what kind of payload is required for pentesting. We had decided to split it into three modules: Stage 0, Stage 1 and Stage 2. The first module, Stage 0, creates and runs the payload. It must generate an artifact, such as a shellcode, a DLL or EXE file, or a VBA script, and provide maximum flexibility by offering customizable parameters for running the payload. This module also handles the circumvention of security measures and monitors the runtime environment.

The second module (Stage 1) must allow the operator to examine the host, perform initial reconnaissance, and then use that information to establish persistence via a payload maintaining covert communications. After successfully establishing persistence, this module must launch the third module (Stage 2) to perform further activities such as lateral movement, privilege escalation, data exfiltration, and credential harvesting.

Three payload modules

The Stage 0 module has to be written from scratch, as available tools quickly get detected by security systems and become useless for penetration testing. To implement the Stage 1 module, we settled on a hybrid approach: partially modifying existing open-source projects while implementing some features in-house. For the third module (Stage 2), we also used open-source projects with minor modifications.

This article details the implementation of the second module (Stage 1) in detail.

Formulating requirements

In light of the objectives outlined above, we will formulate the requirements for the Stage 1 module.

1. Dynamic functionality, or modularity, for increased resilience. In addition, dynamic configuration allows adding techniques via new modules without changing the functional core.
2. Ensuring that the third payload module (Stage 2) runs.
3. Minimal size (100–200 KB) and minimal traces left in the system.
4. The module must comply with OPSEC principles and allow operations to run undetected by security controls. This means we must provide a mechanism for evading signature-based memory scanning.
5. Employing non-standard (hidden) communication channels, outside of HTTP and TCP, to establish covert persistence and avoid network detection.

Choosing the best solution

While defining the requirements, we recognized the need for a modular design. To begin, we need to determine the best way to add new features while running the tasks. One widely used method for dynamically adding functionality is reflective DLL injection, introduced in 2008. This type of injection has both its upsides and downsides. The ReflectiveLoader function is fairly easy to detect, so we’d need a custom implementation for a dynamic configuration. This is an effective yet costly way of achieving modularity, so we decided to keep looking.

The PowerShell Empire framework, whose loader is based on reflective PowerShell execution, gained popularity in the mid-2010s. The introduction of strict monitoring and rigid policies surrounding PowerShell marked the end of its era, with .NET assemblies, executed reflectively using the Assembly.Load method, gaining popularity. Around this time, toolkits like SharpSploit and GhostPack emerged. Cobalt Strike’s execute-assembly feature, introduced in 2018, allowed for .NET assembly injection into a newly created process. Process creation followed by injection is a strong indicator of compromise and is subject to rigorous monitoring. Injecting code requires considerable planning and tailored resources, plus it’s easily detectable. It’s best used after you’ve already performed initial reconnaissance and established persistence.

The next stage of framework evolution is the execution of object files in memory. An object file (COFF, Common Object File Format) is a file that represents a compiled version of the source code. Object files are typically not full-fledged programs: they are needed to link and build a project. An object file includes several important elements ensuring that the executable code functions correctly.

• Header contains information about the architecture, timestamp, number of sections and symbols, and other metadata.
• Sections are blocks that may include assembly code, debugging information, linker directives, exception information, and static data.
• Symbol table contains functions and variables, and information about their location in memory.

Using object files allows you to avoid loading a CLR environment into the process, such as when using a .NET assembly and the Assembly.Load method.

Moreover, COFF is executed in the current context, without the need to create a process and inject the code into it. The feature was introduced and popularized in 2020 by the developers of the Cobalt Strike framework. And in 2021, TrustedSec developed the open-source COFF Loader that serves the same purpose: the tool loads a COFF file from disk and runs it. This functionality perfectly aligns with our objectives because it enables us to perform the required actions: surveying, gaining persistence within the system and initiating the next module via an object file – if we incorporate network retrieval and in-memory execution of the file in the project. In addition, when using COFF Loader, the pentester can remain undetected in the system for a long time.

To interact with the agent in this study, we decided to use BOFs (Beacon Object Files) designed for Cobalt Strike Beacon. The internet offers a wide variety of open-source tools and functions created for BOFs. By using different BOFs as separate modules, we can easily add new techniques at any time without modifying the agent’s core.

Another key requirement for Stage 1 is a minimal payload size. Several approaches can achieve this: for instance, using C# can result in a Stage 1 size of around 20 KB. This is quite good, but the payload will then have a dependency on the .NET framework. If we use a native language like C, the unencrypted payload will be approximately 50 KB, which fits our needs.

Our payload requirements are supported by the Mythic framework. Its microservice architecture makes it easy to add arbitrary server-side functionality. For example, the module assembly process takes place inside a container and is fully defined by us. This allows us to replace specific strings with arbitrary values if detected. Furthermore, Mythic supports both standard communication protocols (HTTPS, TCP) and covert channels, such as encrypted communication over Slack or Telegram. Finally, the use of C ensures a small payload size. All of these factors make the Mythic framework and the agent interacting with it to execute BOFs an optimal choice for launching the second module.

Communication model

In the communication process between the agent and the framework, we need to focus on three elements: payload containers, C2 profile containers, and the translation container. Payload containers hold the agent’s source code and are responsible for building the payload. C2 profile containers are responsible for communicating with the agent. They must receive traffic from the agent and send it to Mythic for further processing. The translation container handles the encryption and decryption of network traffic. We’ll be using HTTP when interacting with Mythic, so the C2 profile will be a web server listening on ports 80 and 443.

Communication flow between the agent and the Mythic framework

Loading an object file

To load and execute an object file, the agent must read the .text section and replace all zeros with relative addresses of external functions and static data. This is known as symbol relocation, which addresses references within a particular section of the object file. Furthermore, the agent places these symbols in memory, for example, after the code section.

To find external functions, we’ll have to analyze the libraries specified in the linker directives of the object file. To do this, we used the functions LoadLibrary, GetModuleHandle and GetProcAddress.

The diagram below clarifies how an object file is loaded and memory is allocated for its components.

Object file representation on disk (left) and in memory (right)

The downsides of the solution

The method described above has a number of shortcomings. Because object file execution is blocking, multiple tasks cannot run simultaneously. For long-term tasks, other methods such as process injection are necessary; however, this is not a critical flaw for the second module, as it is not intended for long-running tasks.

Several other shortcomings are difficult to mitigate. For example, since the object file is executed in the current thread, a critical error will terminate the process. Furthermore, during the execution of the object file in memory, the VirtualAlloc function is used for section mapping and relocation. A call to this WinAPI might alert the security system.

Implementing additional functionality during development and compilation can help complicate analysis and detection for more efficient pentesting and a longer agent life cycle.

Conclusion

Mythic’s features make it a convenient pentesting tool that covers the bulk of pentesting objectives. To utilize this framework efficiently, we created an agent that extends ready-made solutions with our own code. This configuration gave us suitable flexibility and enhanced protection against detection, which is most of what a pentester asks of a working tool.

securelist.com/agent-for-mythi…

LTSpice is a tool that every electronics nerd should have at least a basic knowledge of. Those of us who work professionally in the analog and power worlds rely heavily on the validity of our simulations. It’s one of the basic skills taught at college, and essential to truly understand how a circuit behaves. [Mano] has quite a collection of videos about the tool, and here is a great video explanation of how a bootstrap circuit works, enabling a high-side driver to work in the context of driving a simple buck converter. However, before understanding what a bootstrap is, we need to talk a little theory.

Bootstrap circuits are very common when NMOS (or NPN) devices are used on the high side of a switching circuit, such as a half-bridge (and by extension, a full bridge) used to drive a motor or pump current into a power supply.
A simple half-bridge driving illustrates the high-side NMOS driving problem.
From a simplistic viewpoint, due to the apparent symmetry, you’d want to have an NMOS device at the bottom and expect a PMOS device to be at the top. However, PMOS and PNP devices are weaker, rarer and more expensive than NMOS, which is all down to the device physics; simply put, the hole mobility in silicon and most other semiconductors is much lower than the electron mobility, which results in much less current. Hence, NMOS and NPN are predominant in power circuits.

As some will be aware, to drive a high-side switching transistor, such as an NPN bipolar or an NMOS device, the source end will not be at ground, but will be tied to the switching node, which for a power supply is the output voltage. You need a way to drive the gate voltage in excess of the source or emitter end by at least the threshold voltage. This is necessary to get the device to fully turn on, to give the lowest resistance, and to cause the least power dissipation. But how do you get from the logic-level PWM control waveform to what the gate needs to switch correctly?

The answer is to use a so-called bootstrap capacitor. The idea is simple enough: during one half of the driving waveform, the capacitor is charged to some fixed voltage with respect to ground, since one end of the capacitor will be grounded periodically. On the other half cycle, the previously grounded end, jumps up to the output voltage (the source end of the high side transistor) which boosts the other side of the capacitor in excess of the source (because it got charged already) providing a temporary high-voltage floating supply than can be used to drive the high-side gate, and reliably switch on the transistor. [Mano] explains it much better in a practical scenario in the video below, but now you get the why and how of the technique.

We see videos about LTSpice quite a bit, like this excellent YouTube resource by [FesZ] for starters.

youtube.com/embed/Bh9ZN6GY3qI?…

hackaday.com/2025/05/13/simula…

...per fortuna Bufale le smentisce, anche se in un mondo normale basterebbe il buon senso.

BUTAC

2025-05-13 06:52:33

I vaccini anti Covid NON sono “vaccini”? butac.it/i-vaccini-anti-covid-…

I vaccini anti Covid NON sono “vaccini”?

Sta circolando un testo, in versioni lievemente diverse, che vi riportiamo da Facebook per come ci è stato segnalato: Magnifica e importante sentenza della Corte Suprema degli Stati Uniti: I vaccini anti Covid NON sono "vaccini". Roberto F.

^{maicolengel butac (Butac – Bufale Un Tanto Al Chilo)}

L’OAD (Osservatorio Attacchi Digitali in Italia) è l’unica indagine in Italia che raccoglie dati sugli attacchi digitali intenzionali ai sistemi informativi e sulle relative misure di sicurezza, attraverso un questionario anonimo compilabile online. L’obiettivo è fornire un quadro aggiornato e realistico della situazione della sicurezza digitale nel Paese, utile sia per le aziende che per le pubbliche amministrazioni.

Struttura dell’indagine

Il Questionario si articola in due principali parti: quella sugli attacchi subiti e rilevati nel 2024, con approfondimenti “verticali” sugli attacchi ai siti e agli ambienti web del Sistema Informativo (SI) dell’azienda/ente rispondente, sulle applicazioni/servizi basati su Intelligenza Artificiale e sugli ambienti OT, Operational Technology eventualmente utilizzati dall’Azienda/Ente rispondente; e quella sulle misure di sicurezza digitali in uso, sia tecniche che organizzative.

Questa seconda parte è opzionale ma si suggerisce di compilarla per poter avere alla fine della compilazione una macro valutazione del livello di sicurezza digitale del SI oggetto delle risposte e, nel rispondere, farsi un quadro ed una veloce verifica delle principali misure di sicurezza tecniche ed organizzative che dovrebbero/potrebbero essere implementate in ogni moderno e sicuro SI.

Al termine della compilazione, i partecipanti ricevono una valutazione qualitativa del livello di sicurezza digitale del proprio sistema informativo.

Edizione 2025

L’edizione 2025 dell’OAD è attualmente in corso, rappresentando il 18° anno consecutivo di questa iniziativa. Il questionario è disponibile online e può essere compilato da responsabili IT, CISO, CIO e altri professionisti della sicurezza informatica. I risultati dell’indagine saranno presentati in un evento previsto per l’estate 2025.

Dove trovare i rapporti

I rapporti annuali dell’OAD, contenenti analisi dettagliate e dati statistici sugli attacchi digitali in Italia, sono disponibili gratuitamente sul sito ufficiale dell’iniziativa: www.oadweb.it. Questi documenti rappresentano una risorsa preziosa per comprendere l’evoluzione delle minacce informatiche nel contesto italiano.

Compila il rapporto relativo al 2025 : oadweb.it/LS2025/limesurvey/in…

L'articolo Attacchi informatici in Italia: parte l’OAD 2025, l’indagine più attesa sulla sicurezza digitale proviene da il blog della sicurezza informatica.

Ovvero... da una parte c'è il gruppo di chi è certo sarà il futuro dell'umanità e che grazie a lei supereremo in un attimo tutti i problemi con cui la nostra specie si è dovuta confrontare negli ultimi 10.000 anni e dall'altra il gruppo di quelli che la considerano il Maligno in formato binario.

Tra i due, il (quasi) nulla.

Ora... calcolate la media e ditemi se mi sono sbagliato.