Wavestone was present during the 2025 edition of Barb’hack, a French cybersecurity conference happening yearly in Toulon. You will find below bits and pieces from what we deemed were the most interesting conferences.
Keeping Responder Relevant: The Hidden Potential of Name Resolution Poisoning
Speaker: Quentin Roland
Quentin Roland’s talk revisited a set of techniques that are often dismissed as “old-school”: poisoning local name resolution protocols like LLMNR, NBNS, or mDNS. While these attacks are usually thought of as a way to quietly capture SMB authentications, the presentation showed that Windows’ built-in behaviors can turn them into a much more serious threat. In particular, the WebDAV fallback and Kerberos relaying can be combined to turn routine network noise into a pathway for domain compromise.
The WebDAV Fallback Trick
In a typical Windows environment, SMB authentication is everywhere. Poisoning SMB requests with tools like Responder can capture credentials, but most of the time these are machine accounts or authentications that can’t be relayed because SMB enforces strict integrity checks. As a result, many captured authentications are effectively useless for attackers.
The talk highlighted an often-overlooked behavior: Windows will sometimes retry failed SMB connections over HTTP using the WebDAV protocol. This happens through the WebClient service, which is installed by default on most machines. The trick lies in how Windows interprets different error codes. By default, when an SMB login fails, the server responds with a “STATUS_ACCESS_DENIED” status. Windows stops at that point. But if the server responds with a “STATUS_LOGON_FAILURE” instead, the operating system interprets this as a problem with the protocol rather than with the credentials. It retries the connection using WebDAV, effectively transforming an SMB authentication into an HTTP authentication.
This fallback opens a surprising avenue for attackers. HTTP authentications do not enforce signing by default, which means they can be relayed to services like LDAP without being blocked by the protections that make SMB less useful. A poisoned SMB request that would otherwise be wasted suddenly becomes a live, relayed authentication that can be used to enumerate Active Directory, spray passwords, or even create new machine accounts.
The main limitation is that the WebClient service must be running. While it is installed by default, it isn’t always active unless the user or a process has accessed a WebDAV share. Still, where it is enabled, this fallback represents a subtle but powerful way to pivot within a network.
Combining WebDAV Fallback with Kerberos Relaying
The second part of the talk explored how this fallback can be extended to Kerberos, which is particularly relevant in environments where NTLM has been disabled. Kerberos relaying is usually tricky because tickets are bound to specific services. However, by controlling hostname resolution through LLMNR or NBNS, an attacker can trick a client into requesting a Kerberos ticket for any service of their choosing.
With LLMNR poisoning, the attacker is in control of the hostname resolution. By answering with a chosen service name — for example, pointing to an ADCS (Active Directory Certificate Services) instance — the victim generates a Kerberos ticket for that service and sends it straight to the attacker. Using krbrelayx, the attacker can then relay that ticket to ADCS and request a certificate. Once a valid certificate is obtained, it can be used to request a TGT, opening the door to full domain compromise.
Now comes the clever part: chaining both ideas together. By combining the WebDAV fallback (responder -E flag) with the Kerberos relaying trick (responder -N flag), SMB traffic can be turned into HTTP WebDAV retries that carry Kerberos tickets. Those tickets can then be relayed directly to ADCS. The attack chain is surprisingly short:
- Victim tries to connect to a nonexistent SMB share.
- Responder poisons the request, forcing a WebDAV retry.
- The retry is done over HTTP with Kerberos authentication, using the attacker’s chosen service name.
- The Kerberos ticket is relayed to ADCS with
krbrelayx. - ADCS issues a certificate, which the attacker uses to get a TGT.
The demo showed exactly this: what started as a harmless SMB lookup ended with a valid certificate and the ability to impersonate domain users.
Takeaways
-
Fallbacks matter: Windows’ WebClient can silently turn SMB into HTTP, bypassing protections meant to stop relaying.
-
LLMNR still bites: Even when NTLM is off, Kerberos tickets can be coerced and relayed if LLMNR is active.
-
Defense: disable the WebClient service, block or disable LLMNR/NBNS, and tighten ADCS protections. Otherwise, attackers can chain these primitives into devastating relays.
In conclusion, the presentation demonstrated how Windows’ built-in fallback behaviors and overlooked protocol details can transform seemingly harmless network traffic into a serious threat. SMB authentications that would otherwise be discarded can be converted into relayable HTTP requests, and Kerberos tickets can be redirected to sensitive services to obtain valid certificates. For defenders, the takeaways are straightforward: disabling LLMNR and NBNS, stopping the WebClient service unless necessary, and hardening ADCS certificate issuance policies are key measures. Left unchecked, what appears to be ordinary background traffic on the network can become a pathway to full domain compromise.
Links to the articles:
Hacking a Metro Ticket
Speaker : Raphael Attias (rapatt)
This talk was a dive into something both fun and a bit worrying: how easy it can be to hack metro tickets with a Flipper Zero.
For those not familiar, the Flipper Zero is a pocket-sized multi-tool that can interact with various radio protocols, RFID, NFC, and more. While it can’t read every NFC type, it works with a lot of common ones — including the MiFare Ultralight cards used in many metro systems, festivals, and even hospitals.
The speaker started by walking through the evolution of metro tickets: first punched paper, then magnetic stripes, and now RFID/NFC. In his city, the tickets use MiFare Ultralight, which comes with between 48 and 144 bytes of memory and a 7-byte UID. Pretty small and simple compared to more modern cards.
The key detail: when a ticket is validated at a metro gate, the system simply updates one byte on page 3 of the card to mark it as “used.” That means if you can read and write to that sector, you can basically reset the ticket back to “unused” and ride again. The speaker spent nine months analyzing his card, dumping the data before and after validation, and mapping which bytes controlled what. Eventually, he managed to modify the data in a way that gave him unlimited rides.
It didn’t stop there. He was even able to clone the ticket onto his Flipper Zero, use it directly at metro gates, show it to inspectors, and even recharge it at official machines. All because the system trusted the data stored on the card rather than handling everything server-side.
Of course, the attack has its limits. It depends heavily on the ticketing system — not all cities use MiFare Ultralight, and more advanced implementations would catch this. Also, handling things like transfers and expiration dates requires modifying additional fields, which complicates the hack. Still, in this particular case, the weak design made unlimited metro travel possible.
The fix seems straightforward: keep only the UID on the card and move all ticket logic to the backend. That way, even if someone rolls back or clones their card, the server-side system knows whether it’s valid or not. As of now, though, the city in question hasn’t corrected the issue — meaning free rides are technically still on the table.
AsRepCatcher – Make everyone in your VLAN AsRepRoastable
Speaker: Yassine OUKESSOU
A new tool called AsRepCatcher has been developed by the SOC Team Leader of the ITrust team. As the author is required to perform regular internal audits, he is faced with the following problem: How can a valid domain account be compromised without credentials?
Although there are many techniques for gaining initial access, environments are becoming increasingly secure and remedies are being more and more applied:
- EternalBlue / PrintNightmare / ZeroLogon: patched machines
- LLMNR / NBT-NS / mDNS Poisoning: protocols disabled
- AsRep Roasting: pre-authentication enabled by default on all accounts
- Kerberoasting: SPNs placed only on service accounts and use of gMSA
- Network shares: reading disabled with anonymous or guest accounts
- Brute force weak passwords: strong password policy
- Relays: signed protocols
- Phishing: users made aware
Although the list is not exhaustive, it represents the majority of tests performed by an internal auditor.
However, what the author noticed is that network access is always provided to the auditor, usually in the area reserved for standard users: the user VLAN. In this VLAN, if a user captures the traffic, he will see packets related to authentication, in particular with NTLM or Kerberos protocols.
It turns out that with the Kerberos protocol, a derivative of the user’s password is used (called a hash) to create the KRB_AS_REP request (in the session key).
Thus, an attacker who can retrieve this request could then attempt to crack the user’s password. This is exactly what the AsRepCatcher tool attempts to do (hence the name).
To retrieve the KRB_AS_REP request, the tool uses a well-known technique called ARP Spoofing:
An article by Veracode explains what ARP spoofing is and how to protect yourself from it: https://www.veracode.com/security/arp-spoofing/
AsRepCatcher modifies the ARP table of legitimate VLAN users, who will now send KRB_AS_REQ requests to the attacker, who can modify them on the fly by changing the source IP to his own and also modifying the encryption algorithms used to create the hash.
This information is important because it allows the attacker to retrieve hashes encrypted with a weak algorithm (in this case RC4, provided the KDC authorizes its use), which will greatly facilitate password cracking (a few seconds with RC4 versus several days with AES).
The tool also has features to be more quiet on the network, such as the option (—disable-spoofing) to reset the ARP tables of users whose hash has already been captured.
To protect against the tool, it is therefore recommended to implement remedies against ARP Spoofing and not to allow the RC4 encryption algorithm on the domain.
Tool link: https://github.com/Yaxxine7/ASRepCatcher
How does the national police force use OSINT to track down wanted persons?
Speaker: Nidhal BEN ALOUI
Every year, 580,000 people are registered in the Wanted Persons File (in french: Fichier des Personnes Recherchés). Each person has a file containing information about their identity (surname, first name, age, etc.), a photograph, the reason for the search, and the action to be taken if the individual is found.
In order to classify the files more easily, categories have been created, including:
- AL: mentally ill;
- IT: banned from the territory;
- M: runaway minors;
- PJ: judicial police searches;
- R: opposition to residence in France;
- S: state security;
- T: debtor to the Treasury;
- V: escapees;
- X: missing persons
- etc.
The French gendarmerie police force is often called upon to search for people on this list as part of investigations. In order to find these individuals, the gendarmerie will then use a combination of open source intelligence (OSINT) and closed source intelligence.
For the OSINT part, the use of social networks, tools, and public websites is widely favored. A particular attention is paid to the results of public tools, which are never considered certain by the police force. With regard to closed sources, the gendarmerie has internal tools, databases, and shared national registers that they can consult during the investigations.
It is also possible for judicial police officers (OPJ) to request access to private information stored by companies via “derogatory requests”. Or even to communicate online with potential suspects via a “pseudonymous investigation.”
However, laws very precisely regulate the actions authorized by the gendarmerie, typically:
- Derogatory requests are permitted in the context of criminal investigations.
- Investigations conducted under pseudonyms require a certification from the Cyber Defense Command (ComCyber)
- Each pseudonym and avatar used in the context of an investigation under a pseudonym is unique and recorded in a list accessible to all judicial police officers in order to avoid investigating each other
- It is not permitted to incite someone to commit a crime (for example, asking a potential suspect to purchase illegal goods)
During the conference, two real-life stories were shared to illustrate these concepts.
Purple Team: Methodology and tooling
Speaker: Mael Auzias
This talk, given by Naval Group, tackled the problem of creating a methodology and tooling in order to perform Purple Teams and include them in a larger audit plan to monitor the evolution of the security level and compare different audited scopes.
Indeed, as a part of the missions an internal audit team have, it is important to have defined audit frameworks in order to properly conduct assignments and compare their different results.
To do so, a member of the Red Team worked with the Blue Team of Naval Group to define a specific framework of testing and results reporting, that will ultimately be used to evaluate the detections and responses of each audited party.
Purple Team presentation
A Purple Team is an exercise during which Red Team and Blue Team work hand in hand, by freely sharing both malicious actions that are executed and detections made. The ultimate goal being to improve both detection capacities and responses made.
To properly prepare a Purple Team, it is thus important to define:
- What kind of attacker profile is to be simulated?
- What TTPs to focus on during the exercise?
- What are the targets of the assignment?
- What are the expected detections and responses?
Once those points are taken care of, the Purple Team assignment can start.
Methodology and tooling dedicated to the internal Purple Team exercises
Perform tests
First, the methodology put in place by Naval Group leverages VECTR, a tool destined to automatize testing and measure detection effectiveness by offering a space to both Red and Blue Teams to collaborate. In this case, it is only used as a wrapper to automatically launch specific attacks and collect responses results.
Grading system
Once the attacks are performed and the detection are determined, the actions are classified in the following table:
Indeed, four cases can be differentiated:
- If an observed detection matches the expected one, the tested malicious action gets the higher rating (here, 7)
- If an observed detection is “lower” than the expected one, it gets a poor rating (between 1 to 3 here)
- If an observed detection is slightly higher (for example a the initiation of an incident investigation instead of a simple event), it gets a rather high rating (between 5 and 6 here)
- Finally, if an observed reaction is disproportionate regarding its expected one, it gets a low rating: triggering a global cyber crisis for an action that should not raise an alert can be incapacitating for an information system.
PS: here, the different categories do not exactly match the ones that were presented during the event.
Final grade
Finally, once every attack categories are tested, a specific math formula computes the final grading of the audited scope in the following graph:
This final grading will allow to deduce the performance of the Blue Team, but also monitor the evolution of this of metric over time.
Conclusion
Thus, by defining a clean audit frame to perform Purple Team, it ensures Naval Group to properly assess the performance of the detections made in the different scopes of the company, compare them and monitor the evolutions over time.
This will assurely be proven efficient the more Purple Team exercise are conducted.
How malicious actors fool researchers with unpopular software
Speaker: Georgy Kucherin
The speaker, a vulnerability researcher at Kaspersky, presents a case study encountered during a real-life mission.
As a network analyst working for a client, the researcher was struck by a result collected in the SIEM.
The domain eventuallogic.com is retrieved and analyzed on the well-known Virus Total platform with a score of 1/97 (meaning that one antivirus program recognizes the domain as suspicious or dangerous, compared to 96 that recognize it as safe).
Given the result, many would not have looked any further, but Georgy continued his investigation out of curiosity.
Upon visiting the website, the company appears to offer software for compressing files. Georgy downloaded it to a VM and tested it. The tool works well despite recurring ads.
At this point, many researchers would classify the software as PUA (= Potentially Unwanted Application), meaning that the software is not desired on a professional workstation (mainly because of the ads), but is not considered dangerous. However, only the IT department can decide to ban this type of software; it is not up to analysts at the SOC (Security Operation Center) to decide, unless there is evidence of malicious activity linked to this software.
Georgy decides to take some time and analyze this software in more depth, starting with an online sandbox: joesandbox.com.
The sandbox then runs the software in a controlled environment and analyzes it. This time, the result is 56/100, indicating that the software failed certain tests.
A file named decrypt.exe is found in the computer’s memory when the software is running. This file is retrieved by Georgy and analyzed on Virus Total, with a score of 5/97. Still not very high, but in the relationships tab, another domain is present: decryptables.com.
By repeating this method several times, Georgy traced the file back to another domain offering compression software: Let’s Compress.
The software was analyzed again on joesandbox, and this time Georgy found that the compression software executed a Python file compiled with pyinstaller.
Georgy performed the following actions:
- Extract the content with pyinstxtractor
- Convert the main.pyc file into readable Python script
- Deobfuscate the resulting .py script
- Decrypt a .json file created by the script
- Find a call to a Command & Control (C2) infrastructure in this json file
After all these investigations, here is proof that the file is malicious.
The reverse path was taken in order to verify the link between the malicious file and the detected base domain.
The point of all this is to prove that malicious actors put in place numerous layers to mislead researchers, and that even a low score from a widely accepted tool such as Virus Total is not enough to judge the trustworthiness of a binary or domain.
Decompiling malicious binaries for Linux with r2ai
Speaker: Axelle Apvrille
During these days where AI meets cybersecurity more than ever, it was impossible not to have a talk about it. In this talk, Axelle presented r2ai, a new plugin for radare2, the well-known reverse engineering framework. The idea is simple yet powerful: combine radare2’s disassembly capabilities with a Large Language Model (LLM) to translate raw assembly into more intelligible source code.
The talk illustrated the tool’s potential with the analysis of two real-world malware samples, showcasing both its strengths and limitations.
Case Study 1: A Tiny but Crafty Shellcode
The first sample was a lightweight 4 KB ELF shellcode, packed with tricks to frustrate static analysis. Looking for strings inside the data section provided nothing of interest, and even Ghidra provided little beyond a cryptic swi instruction.
With r2ai, however, the story was different, the disassembly became far more readable. The model pointed out socket creation and a suspicious connect-back routine. But here came an important caveat: LLMs may “hallucinate”. For instance, the model initially suggested a connection to 127.0.0.1:4444, which turned out to be incorrect after deeper inspection of the actual assembly.
Still, the plugin correctly highlighted another key behavior: a call to mprotect modifying stack memory permissions to RWX: a typical indicator of a stager preparing to fetch and execute a payload from a C2 server.
In this first case, r2ai showed how it could accelerate the discovery of high-level logic, while human analysts remained essential to validate and correct its interpretation.
Case Study 2: Trigona Ransomware on Linux
The second sample was Trigona, a ransomware family usually seen in Windows environments, but with an unexpected Linux variant dating back to May 2023. Interestingly, the code was written in Delphi—a surprising choice that puzzled many in the audience.
Although Trigona was thought to be inactive, samples were still circulating as of April 2025, making the analysis particularly relevant.
Here, r2ai required extra tuning (increasing the maximum tokens of the model’s context) to compensate with the binary’s size, but it revealed crucial behaviors:
- Shutting down virtual machines to maximize disruption,
- Locating and encrypting documents,
- Implementing data exfiltration before encryption.
The researchers emphasized how quickly they could map the entire kill chain, compared with traditional workflows in IDA Pro or Ghidra.
Limits and Takeaways
The presentation ended with a discussion of r2ai’s limitations:
- Token constraints: long analyses may crash or become expensive,
- Accuracy: while LLMs can explain syscalls and control flow, they sometimes “invent” values or logic that analysts must double-check,
- Complementary use: r2ai doesn’t replace standard tools but rather enhances them, accelerating hypothesis-building.
Still, the experiment showed that coupling an AI model with a disassembler opens new perspectives: interactive reverse engineering with natural language queries.
Scanning a network without an IP address, a good idea ?
Speakers: Julien M. & Francis H.
This presentation, given by Naval Group, introduced a way of scanning a network without displaying its IP address by combining the way of functioning of two basic protocols. Two employees were on stage, one form the Red Team and one from the Blue Team.
The protocol basics
To understand the following presentation, it is important to go over two famous protocols: ARP (Address Resolution Protocol) and TCP (Transmission Control Protocol).
ARP
ARP is a protocol dedicated to the discovery of assets present in a network, by associating a MAC address and an IP address.
To perform this discovery step, broadcast requests are sent to ask for the MAC address corresponding to a specific destination IP address if the latter is not known by the network equipment (for example, a router).
TCP
TCP is a communication protocol ensuring reliable, ordered, error-checked data deliver. it relies on SYN requests sent by a source to a destination. Different answers can be expected depending on the accessibility of the destination port:
- If the port is filtered, no answer is sent back as the SYN packet does not reach the destination
- If the port is closed, a RST packet is sent back to the source
- If the port is opened, a SYN+ACK packet is sent back.
Another case can be differnciated: if the port is opened but the source disapears of the network (for example after a network shortage), the SYN+ACK packet is sent several times (for example, 5 for some equipment) by the destination in order to continue the TCP exchange.
Gathering ARP and TCP (and maths)
Thus, a new methodology of scanning emerges of the combination of the way of functionning of ARP and TCP.
The goal is to craft a specific SYN packet, by forging the source address to chose an IP address that is not currently in use in the network, and send it to the victim on the chosen port. Following the response of the destination, and since the source IP adress is unknown by the router, the latter will send ARP broadcast requests to find the source. Furthermore, the number of ARP requests will depend on the state of the port:
- If the port is filtered, there will be no response sent by the destination, and thus no ARP broadcast request
- If the port is closed, there will be one RST packet sent by the destination to the unknown source, and thus one ARP broadcast request
- If the port is opened, there will be several SYN+ACK packets as there won’t be ACK packets sent back by the unknown source, thus several ARP broadcast requests
The attacker will just have to monitor the number of ARP broadcast requests related to the impersonated unknown IP address to deduce the state for the scanned port.
However, some limitations exist: for example, the fact that the number of SYN+ACK packets vary may induce a number of false positive, and makes it more difficult to develop reliable tools.
What does the SOC have to say?
Following the presentation of this methodology, the member of the Blue Team explained the point of view of the SOC regarding this scanning technique.
First, it is important to say that while this scanning technique is quite difficult to detect in real life scenarios, it is only one way out of many to scan a network, which thus represents a tiny fraction of scanning scenario (regarding a MITRE ATT&CK matrix) a SOC has to cover.
Additionally, this scanning scenario only happens when the network has first been breached, and is not the end of the killchain as well. The Blue Team has several other defense mechanisms to stop attacks either upstream or downstream of this malicious action.
Conclusion
Thus, even if this scanning method is quite ingenious, the Blue Teams may not be forced to take it into account and spend time resolving the issue. This conclusion may be even generalized to other future findings: a Blue Team must chose its battle, regarding the severity of the attack techniques and the manpower at disposal.
A Tale of Two Reports: The Trivial Things We’re Told vs. The Vital Things We’re Not
Speaker: Koreth
This talk was all about a problem everyone in security knows too well: we’re buried under alerts, notifications, and reports — but the truly important ones are often the first to be missed.
Silent Ghost kicked things off with some well-known examples. Take the Target breach: 70 million credit cards leaked, and the warning was there, but it looked too much like spam, so nobody acted. Same story in Rouen (2019), where a phishing email dropped malware that spread laterally across the network. The initial alert was flagged, but ignored. Colonial Pipeline in 2021? Again, a notification existed — but nobody paid attention.
And this isn’t a new issue. Back in 2016, the NSA lost sensitive data because an employee simply used a USB stick to exfiltrate it. SolarWinds in 2019 showed how dangerous a compromised CICD pipeline could be, yet very few people noticed the early signs. More recently, Kiabi (2024) faced a €100 million fraud from an internal accountant — red flags were there, but lost in the noise.
The structural issue is clear: only 0.13% of pull requests are labeled “security,” while closer to 15% actually involve security. That gap means real vulnerabilities are hidden in plain sight. Silent Ghost pointed out one CVE that took more than 100 undocumented fixes before it was officially recognized.
Bug bounty programs suffer the same fate. Running private programs at YesWeHack, he sees inboxes flooded with overblown or poorly written reports: emails describing “CVSS 10” vulnerabilities that turn out to be nothing more than a misconfigured header or an exposed Google Maps API key. The sheer volume of this noise risks burying the handful of truly critical findings.
The takeaway was clear: as an industry, we need to cut the noise. Fewer useless notifications, better triage, and clearer reporting standards would help ensure the important alerts get through. Otherwise, the next major breach alert will end up ignored just like the last.
OASIS – Ollama Automated Security Intelligence Scanner
Speaker: psyray (Raynald Coupé)
Another presentation around the usage of AI in the cybersecurity was held about OASIS, an open-source framework designed to analyze source code with the help of AI models, with an accent on confidentiality.
Its creator developed the tool out of necessity: traditional SaaS-based AI solutions raise concerns when working on sensitive client code, making local deployment a must.
As its name implies, OASIS relies on Ollama, a lightweight system that allows developers to run large language models on their own infrastructure. The result is a practical solution for secure, scalable, and customizable code audits.
Architecture and Workflow
At a technical level, OASIS relies on a semantic embedding system: source code is transformed into vectors, enabling contextual analysis beyond simple pattern matching. This foundation allows the AI to spot vulnerabilities in a way that resembles human reasoning. The tool offers multiple modes of operation
- Audit Mode: A quick scan to flag high-risk areas in large codebases. By tuning thresholds, analysts can minimize false positives while still obtaining a strong first-pass overview,
- Standard Scan (two-phase):
- A lightweight model highlights potentially suspicious code,
- A more powerful model performs deep analysis of the flagged sections. This is ideal for large projects with consistent risk profiles.
- Adaptive Scan (multi-level):
- A static scan with patterns and regex (fast and without AI),
- A lightweight model scans for surface issues,
- A contextual analysis with risk scoring,
- An in-depth review using a heavyweight model,
- This tiered approach ensures flexibility: from a quick audit to a comprehensive deep dive.
Detection Capabilities
OASIS is designed to catch a wide range of issues, including
- Web vulnerabilities: XSS, XXE, CSRF,
- Authentication flaws,
- Sensitive data exposure,
- Configuration errors such as path traversal or weak cryptographic suites.
The framework supports multiple programming languages and can even generate Burp Suite requests to validate findings.
Reporting and Outputs
Beyond detection, OASIS generates structured reports in PDF, Markdown, or HTML, documenting:
- The complete attack chain for each vulnerability (entry point, exploitation path, potential impact),
- Remediation recommendations, helping developers fix issues quickly.
This makes the reports usable both for technical teams and for managers needing a higher-level view of project risk.
Post-Incident Lessons from an Industrial Cyber Breach
Speakers: Hack’im et Antxine
This talk was given by two speakers regarding a post-incident feedback.
Indeed, one of their client contacted them after plugging in an USB flash drive on a standard workstation where an EDR triggered an alert. It was suspicious in that case because this flash drive did not raise alerts before, and was only used to update a standalone server separated form the rest of the network.
Beginning of the investigation
Thus, the focus was made on the server, likely to be infected by a malicious program which propagated to the flash drive.
Using classic tools to retrieve the 900GB of the server and analyze the filesystem and evtx files, they discovered a hidden suspicious program in the %APPDATA% folder called aL4N.exe. Indeed, an unkown executable such as this one should not be in this folder, raising the interest of the investigators.
aL4N.exe
Using VirusTotal to evaluate the dangerousness of the executable, it showed a detection index of 52/94, being concerning and then driving the investigators to continue their assessment in this direction.
Following this lead, they discovered that this malwere has been present on the server from the mastering of the latter, back in 2016, and was brought up by a flash drive.
Traces of earlier in-house investigations were found, with a file mentionning the presence of aL4N.exe found by employees.
Written in AutoIT, this malware establishes a communication tunnel to a C2 (Command & Control) server. However, in the case of this malware, when configured, the malicious actor set the remote server address to localhost, denoting a lack of knowledge from the initiator of the attack.
The replication system of this malware is however less classic. As soon as an external storage of more of 1GB is attached to an infected target, aL4N.exe will create a My Pictures folder and hide it, copy itself in it and create a shortcut for My Pictures that will execute aL4N.exe upon clicking.
Conclusion
The main takeout of this talk is to install detection mechanisms on every components of an IS, even if they are separated for the main network. It is also possible to put in place efficient detection and cleaning stations for flash drives to sanitize removable storage devices, even if the ones of this company did not detecte aL4N.exe.
