La musica dell’inno dei Marine – il più antico delle Forze Armate americane - è stata scritta da un italiano, Francesco Maria Scala, adattando un’opera del musicista Jacques Offenbach (1819-1880) la “Genevieve de Brabant”, presentata a Parigi il 19 novembre 1859. Scala – per certi versi sorprendente ad apprendersi - era allora Direttore della Banda dei Marine, ed è stato uno dei quattro di origini italiane che sino ad ora hanno guidato tale prestigioso complesso musicale

Scopri di più su tuttostoria.net 👇
tuttostoria.net/storia-contemp…

ed ascolta su yewtu.be l'Inno dei Marine!
yewtu.be/watch?v=Qqv6tzeJ9R4

#USMB #FrancisScala #MarineBand #storiamilitare

@Storia

Introduction

Cyberthreats are constantly evolving, and email phishing is no exception. Threat actors keep coming up with new methods to bypass security filters and circumvent user vigilance. At the same time, established – and even long-forgotten – tactics have not gone anywhere; in fact, some are getting a second life. This post details some of the unusual techniques malicious actors are employing in 2025.

Using PDF files: from QR codes to passwords

Emails with PDF attachments are becoming increasingly common in both mass and targeted phishing campaigns. Whereas in the past, most PDF files contained phishing links, the main trend in these attacks today is the use of QR codes.

Email with a PDF attachment that contains a phishing QR code

This represents a logical progression from the trend of using QR codes directly in the email body. This approach simplifies the process of disguising the phishing link while motivating users to open the link on their mobile phone, which may lack the security safeguards of a work computer.

Email campaigns that include phishing links embedded in PDF attachments continue to pose a significant threat, but attackers are increasingly employing additional techniques to evade detection. For example, some PDF files are encrypted and protected with a password.

Phishing email with a password-protected PDF attachment

The password may be included in the email that contains the PDF, or it may be sent in a separate message. From the cybersecurity standpoint, this approach complicates quick file scanning, while for the recipients it lends an air of legitimacy to attackers’ efforts and can be perceived as adherence to high security standards. Consequently, these emails tend to inspire more user trust.

PDF file after the user enters the password

Phishing and calendar alerts

The use of calendar events as a spam technique, which was popular in the late 2010s but gradually faded away after 2019, is a relatively old tactic. The concept is straightforward: attackers send an email that contains a calendar appointment. The body of the email may be empty, but a phishing link is concealed in the event description.

Blank email with a phishing link in the calendar appointment

When the recipient opens the email, the event is added to their calendar – along with the link. If the user accepts the meeting without thoroughly reviewing it, they will later receive a reminder about it from the calendar application. As a result, they risk landing on the phishing website, even if they chose not to open the link directly in the original message.

In 2025, phishers revived this old tactic. However, unlike the late 2010s, when these campaigns were primarily mass mailshots designed with Google Calendar in mind, they are now being used in B2B phishing and specifically target office workers.

Phishing sign-in form for a Microsoft account from a calendar phishing attack

Verifying existing accounts

Attackers are not just updating the methods they use to deliver phishing content, but also the phishing websites. Often, even the most primitive-looking email campaigns distribute links to pages that utilize new techniques.

Voice message phishing

For example, we observed a minimalistic email campaign crafted to look like an alert about a voice message left for the user. The body of the email contained only a couple of sentences, often with a space in the word “voice”, and a link. The link led to a simple landing page that invited the recipient to listen to the message.

Landing page that opens when clicking the link in the phishing email

However, if the user clicks the button, the path does not lead to a single page but rather a chain of verification pages that employ CAPTCHA. The purpose is likely to evade detection by security bots.

The CAPTCHA verification chain

After repeatedly proving they are not a bot, the user finally lands on a website designed to mimic a Google sign-in form.

The phishing sign-in form

This page is notable for validating the Gmail address the user enters and displaying an error if it is not a registered email.

Error message

If the victim enters a valid address, then, regardless whether the password is correct or not, the phishing site will display another similar page, with a message indicating that the password is invalid. In both scenarios, clicking “Reset Session” opens the email input form again. If a distracted user attempts to log in by trying different accounts and passwords, all of these end up in the hands of the attackers.

MFA evasion

Because many users protect their accounts with multi-factor authentication, scammers try to come up with ways to steal not just passwords but also one-time codes and other verification data. Email phishing campaigns that redirect users to sites designed to bypass MFA can vary significantly in sophistication. Some campaigns employ primitive tactics, while others use well-crafted messages that are initially difficult to distinguish from legitimate ones. Let’s look at an email that falls in the latter category.

Phishing email that mimics a pCloud notification

Unlike most phishing emails that try to immediately scare the user or otherwise grab their attention, the subject here is quite neutral: a support ticket update from the secure cloud storage provider pCloud that asks the user to evaluate the quality of the service. No threats or urgent calls to action. If the user attempts to follow the link, they are taken to a phishing sign-in form visually identical to the original, but with one key difference: instead of pcloud.com, the attackers use a different top-level domain, p-cloud.online.

The phishing sign-in form

At every step of the user’s interaction with the form on the malicious site, the site communicates with the real pCloud service via an API. Therefore, if a user enters an address that is not registered with the service, they will see an error, as if they were signing in to pcloud.com. If a real address is entered, a one-time password (OTP) input form opens, which pCloud also requests when a user tries to sign in.

OTP input form

Since the phishing site relays all entered data to the real service, an attempt to trick the verification process will fail: if a random combination is entered, the site will respond with an error.

Attempting to bypass verification

The real OTP is sent by the pCloud service to the email address the user provided on the phishing site.

OTP email

Once the user has “verified” the account, they land on the password input form; this is also requested by the real service. After this step, the phishing page opens a copy of the pCloud website, and the attacker gains access to the victim’s account. We have to give credit to the scammers: this is a high-quality copy. It even includes a default folder with a default image identical to the original, which may delay the user’s realization that they have been tricked.

Password input form

Conclusion

Threat actors are increasingly employing diverse evasion techniques in their phishing campaigns and websites. In email, these techniques include PDF documents containing QR codes, which are not as easily detected as standard hyperlinks. Another measure is password protection of attachments. In some instances, the password arrives in a separate email, adding another layer of difficulty to automated analysis. Attackers are protecting their web pages with CAPTCHAs, and they may even use more than one verification page. Concurrently, the credential-harvesting schemes themselves are becoming more sophisticated and convincing.

To avoid falling victim to phishers, users must stay sharp:

• Treat unusual attachments, such as password-protected PDFs or documents using a QR code instead of a link to a corporate website, with suspicion.
• Before entering credentials on any web page, verify that the URL matches the address of the legitimate online service.

Organizations are advised to conduct regular security training for employees to keep them up-to-date on the latest techniques being used by threat actors. We also recommend implementing a reliable solution for email server security. For example, Kaspersky Security for Mail Server detects and blocks all the attack methods described in this article.

securelist.com/email-phishing-…

Introduction

Back in 2024, we gave a brief description of a complex cyberespionage campaign that we dubbed “PassiveNeuron”. This campaign involved compromising the servers of government organizations with previously unknown APT implants, named “Neursite” and “NeuralExecutor”. However, since its discovery, the PassiveNeuron campaign has been shrouded in mystery. For instance, it remained unclear how the implants in question were deployed or what actor was behind them.

After we detected this campaign and prevented its spreading back in June 2024, we did not see any further malware deployments linked to PassiveNeuron for quite a long time, about six months. However, since December 2024, we have observed a new wave of infections related to PassiveNeuron, with the latest ones dating back to August 2025. These infections targeted government, financial and industrial organizations located in Asia, Africa, and Latin America. Since identifying these infections, we have been able to shed light on many previously unknown aspects of this campaign. Thus, we managed to discover details about the initial infection and gather clues on attribution.

SQL servers under attack

While investigating PassiveNeuron infections both in 2024 and 2025, we found that a vast majority of targeted machines were running Windows Server. Specifically, in one particular infection case, we observed attackers gain initial remote command execution capabilities on the compromised server through the Microsoft SQL software. While we do not have clear visibility into how attackers were able to abuse the SQL software, it is worth noting that SQL servers typically get compromised through:

• Exploitation of vulnerabilities in the server software itself
• Exploitation of SQL injection vulnerabilities present in the applications running on the server
• Getting access to the database administration account (e.g. by brute-forcing the password) and using it to execute malicious SQL queries

After obtaining the code execution capabilities with the help of the SQL software, attackers deployed an ASPX web shell for basic malicious command execution on the compromised machine. However, at this stage, things did not go as planned for the adversary. The Kaspersky solution installed on the machine was preventing the web shell deployment efforts, and the process of installing the web shell ended up being quite noisy.

In attempts to evade detection of the web shell, attackers performed its installation in the following manner:

1. They dropped a file containing the Base64-encoded web shell on the system.
2. They dropped a PowerShell script responsible for Base64-decoding the web shell file.
3. They launched the PowerShell script in an attempt to write the decoded web shell payload to the filesystem.

As Kaspersky solutions were preventing the web shell installation, we observed attackers to repeat the steps above several times with minor adjustments, such as:

• Using hexadecimal encoding of the web shell instead of Base64
• Using a VBS script instead of a PowerShell script to perform decoding
• Writing the script contents in a line-by-line manner

Having failed to deploy the web shell, attackers decided to use more advanced malicious implants to continue the compromise process.

Malicious implants

Over the last two years, we have observed three implants used over the course of PassiveNeuron infections, which are:

• Neursite, a custom C++ modular backdoor used for cyberespionage activities
• NeuralExecutor, a custom .NET implant used for running additional .NET payloads
• the Cobalt Strike framework, a commercial tool for red teaming

While we saw different combinations of these implants deployed on targeted machines, we observed that in the vast majority of cases, they were loaded through a chain of DLL loaders. The first-stage loader in the chain is a DLL file placed in the system directory. Some of these DLL file paths are:

• C:\Windows\System32\wlbsctrl.dll
• C:\Windows\System32\TSMSISrv.dll
• C:\Windows\System32\oci.dll

Storing DLLs under these paths has been beneficial to attackers, as placing libraries with these names inside the System32 folder makes it possible to automatically ensure persistence. If present on the file system, these DLLs get automatically loaded on startup (the first two DLLs are loaded into the svchost.exe process, while the latter is loaded into msdtc.exe) due to the employed Phantom DLL Hijacking technique.

It also should be noted that these DLLs are more than 100 MB in size — their size is artificially inflated by attackers by adding junk overlay bytes. Usually, this is done to make malicious implants more difficult to detect by security solutions.

On startup, the first-stage DLLs iterate through a list of installed network adapters, calculating a 32-bit hash of each adapter’s MAC address. If neither of the MAC addresses is equal to the value specified in the loader configuration, the loader exits. This MAC address check is designed to ensure that the DLLs get solely launched on the intended victim machine, in order to hinder execution in a sandbox environment. Such detailed narrowing down of victims implies the adversary’s interest towards specific organizations and once again underscores the targeted nature of this threat.

Having checked that it is operating on a target machine, the loader continues execution by loading a second-stage loader DLL that is stored on disk. The paths where the second-stage DLLs were stored as well as their names (examples include elscorewmyc.dll and wellgwlserejzuai.dll) differed between machines. We observed the second-stage DLLs to also have an artificially inflated file size (in excess of 60 MB), and the malicious goal was to open a text file containing a Base64-encoded and AES-encrypted third-stage loader, and subsequently launch it.

Snippet of the payload file contents

This payload is a DLL as well, responsible for launching a fourth-stage shellcode loader inside another process (e.g. WmiPrvSE.exe or msiexec.exe) which is created in suspended mode. In turn, this shellcode loads the final payload: a PE file converted to a custom executable format.

In summary, the process of loading the final payload can be represented with the following graph:

Final payload loading

It is also notable that attackers attempted to use slightly different variants of the loading scheme for some of the target organizations. For example, we have seen cases without payload injection into another process, or with DLL obfuscation on disk with VMProtect.

The Neursite backdoor

Among the three final payload implants that we mentioned above, the Neursite backdoor is the most potent one. We dubbed it so because we observed the following source code path inside the discovered samples: E:\pro\code\Neursite\client_server\nonspec\mbedtls\library\ssl_srv.c. The configuration of this implant contains the following parameters:

• List of C2 servers and their ports
• List of HTTP proxies that can be used to connect to C2 servers
• List of HTTP headers used while connecting to HTTP-based C2 servers
• A relative URL used while communicating with HTTP-based C2 servers
• A range of wait time between two consecutive C2 server connections
• A byte array of hours and days of the week when the backdoor is operable
• An optional port that should be opened for listening to incoming connections

The Neursite implant can use the TCP, SSL, HTTP and HTTPS protocols for C2 communications. As follows from the configuration, Neursite can connect to the C2 server directly or wait for another machine to start communicating through a specified port. In cases we observed, Neursite samples were configured to use either external servers or compromised internal infrastructure for C2 communications.

The default range of commands implemented inside this backdoor allows attackers to:

• Retrieve system information.
• Manage running processes.
• Proxy traffic through other machines infected with the Neursite implant, in order to facilitate lateral movement.

Additionally, this implant is equipped with a component that allows loading supplementary plugins. We observed attackers deploy plugins with the following capabilities:

• Shell command execution
• File system management
• TCP socket operations

The NeuralExecutor loader

NeuralExecutor is another custom implant deployed over the course of the PassiveNeuron campaign. This implant is .NET based, and we found that it employed the open-source ConfuserEx obfuscator for protection against analysis. It implements multiple methods of network communication, namely TCP, HTTP/HTTPS, named pipes, and WebSockets. Upon establishing a communication channel with the C2 server, the backdoor can receive commands allowing it to load .NET assemblies. As such, the main capability of this backdoor is to receive additional .NET payloads from the network and execute them.

Tricky attribution

Both Neursite and NeuralExecutor, the two custom implants we found to be used in the PassiveNeuron campaign, have never been observed in any previous cyberattacks. We had to look for clues that could hint at the threat actor behind PassiveNeuron.

Back when we started investigating PassiveNeuron back in 2024, we spotted one such blatantly obvious clue:

Function names found inside NeuralExecutor

In the code of the NeuralExecutor samples we observed in 2024, the names of all functions had been replaced with strings prefixed with “Супер обфускатор”, the Russian for “Super obfuscator”. It is important to note, however, that this string was deliberately introduced by the attackers while using the ConfuserEx obfuscator. When it comes to strings that are inserted into malware on purpose, they should be assessed carefully during attribution. That is because threat actors may insert strings in languages they do not speak, in order to create false flags intended to confuse researchers and incident responders and prompt them to make an error of judgement when trying to attribute the threat. For that reason, we attached little evidential weight to the presence of the “Супер обфускатор” string back in 2024.

After examining the NeuralExecutor samples used in 2025, we found that the Russian-language string had disappeared. However, this year we noticed another peculiar clue related to this implant. While the 2024 samples were designed to retrieve the C2 server addresses straight from the configuration, the 2025 ones did so by using the Dead Drop Resolver technique. Specifically, the new NeuralExecutor samples that we found were designed to retrieve the contents of a file stored in a GitHub repository, and extract a string from it:

Contents of the configuration file stored on GitHub

The malware locates this string by searching for two delimiters, wtyyvZQY and stU7BU0R, that mark the start and the end of the configuration data. The bytes of this string are then Base64-decoded and decrypted with AES to obtain the C2 server address.

Snippet of the implant configuration

It is notable that this exact method of obtaining C2 server addresses from GitHub, using a string containing delimiter sequences, is quite popular among Chinese-speaking threat actors. For instance, we frequently observed it being used in the EastWind campaign, which we previously connected to the APT31 and APT27 Chinese-speaking threat actors.

Furthermore, during our investigation, we learned one more interesting fact that could be useful in attribution. We observed numerous attempts to deploy the PassiveNeuron loader in one particular organization. After discovering yet another failed deployment, we have detected a malicious DLL named imjp14k.dll. An analysis of this DLL revealed that it had the PDB path G:\Bee\Tree(pmrc)\Src\Dll_3F_imjp14k\Release\Dll.pdb. This PDB string was referenced in a report by Cisco Talos on activities likely associated with the threat actor APT41. Moreover, we identified that the discovered DLL exhibits the same malicious behavior as described in the Cisco Talos report. However, it remains unclear why this DLL was uploaded to the target machine. Possible explanations could be that the attackers deployed it as a replacement for the PassiveNeuron-related implants, or that it was used by another actor who compromised the organization simultaneously with the attackers behind PassiveNeuron.

When dealing with attribution of cyberattacks that are known to involve false flags, it is difficult to understand which attribution indicators to trust, or whether to trust any at all. However, the overall TTPs of the PassiveNeuron campaign most resemble the ones commonly employed by Chinese-speaking threat actors. Since TTPs are usually harder to fake than indicators like strings, we are, as of now, attributing the PassiveNeuron campaign to a Chinese-speaking threat actor, albeit with a low level of confidence.

Conclusion

The PassiveNeuron campaign has been distinctive in the way that it primarily targets server machines. These servers, especially the ones exposed to the internet, are usually lucrative targets for APTs, as they can serve as entry points into target organizations. It is thus crucial to pay close attention to the protection of server machines. Wherever possible, the attack surface associated with these servers should be reduced to a minimum, and all server applications should be monitored to prevent emerging infections in a timely manner. Specific attention should be paid to protecting applications against SQL injections, which are commonly exploited by threat actors to obtain initial access. Another thing to focus on is protection against web shells, which are deployed to facilitate compromise of servers.

Indicators of compromise

PassiveNeuron-related loader files
12ec42446db8039e2a2d8c22d7fd2946
406db41215f7d333db2f2c9d60c3958b
44a64331ec1c937a8385dfeeee6678fd
8dcf258f66fa0cec1e4a800fa1f6c2a2
d587724ade76218aa58c78523f6fa14e
f806083c919e49aca3f301d082815b30

Malicious imjp14k.dll DLL
751f47a688ae075bba11cf0235f4f6ee

securelist.com/passiveneuron-c…

If you think about it, STL files are like PDF files. You usually create them using some other program, export them, and then expect them to print. But you rarely do serious editing on a PDF or an STL. But what if you don’t have anything but the STL? [The Savvy Engineer] has a method to help you if you need to reverse engineer an STL file in FreeCAD. Check it out in the video below.

The problem is, of course, that STLs are made up of numerous little triangles. The trick is to switch workbenches and create a shape from mesh. That gets you part of the way.

Once you have a shape, you can convert it to a solid. At that point, you can create a refined copy. This gives you a proper CAD file that you can export to a STEP file. From there, you can use it in FreeCAD or nearly any other CAD package you like to use.

Once you have a proper object, you can easily use it like any other solid body in your CAD program. This is one of those things you won’t need every day, but when you do need it, it’ll come in handy.

Want to up your FreeCAD game? We can help. There are other ways to hack up STL files. You can even import them into TinkerCAD to do simple things, but they still aren’t proper objects.

youtube.com/embed/TddS7qhcDng?…

hackaday.com/2025/10/21/revers…