Zyxel vulnerability exploited by “Helldown” ransomware group

Back to Posts

Zyxel vulnerability exploited by “Helldown” ransomware group

Reading Time: 16 minutes

Introduction

As Yarix’s Incident Response Team, our responsibilities are to manage critical issues related to cyber-attacks carried out by cybercriminals, intervening promptly in order to guarantee security to victim companies and to minimize latent risks, analyzing the systems within their infrastructures and indicating precise remediation actions capable of re-establishing a state of security sufficient for normal operational recovery.

In the course of our activities, therefore, we are called upon to analyze the events that occurred on a case-by-case basis, reconstructing the attack chain used by the Threat Actor (TA: malicious actor, cybercriminal) to penetrate the implemented perimeter defenses and then, exploiting the foothold obtained in the corporate infrastructure, to extend its control within it for malicious purposes.

The first weaknesses to be exploited by attackers are those exposed by the infrastructure, which can be present within published portals, services exposed to the Internet and the public or even, in some cases, in appliances deployed on the perimeter to defend the infrastructure, such as Firewall devices, which can sometimes represent a weakness in the layered defense if not maintained and updated correctly or having vulnerable code. There is another risk, in fact, that is that one of these components has what is described as a Zero-Day vulnerability, i.e. a vulnerability still unknown to the public and often even to the vendor itself, for which no corrective security patch has yet been released: this condition configures as a high risk, since when the exploitation of the vulnerability can allow cybercriminals to execute remote commands, there are specific techniques to exploit the technologies used in the infrastructure, bypassing defenses and allowing greater compromise of the same, up to, in the most disastrous cases, its total compromise and inoperability.

The aim of attackers is very often to profit through mechanisms such as blackmail. This is done by threatening the publication of company data exfiltrated from databases or servers during the perpetrated attack, within their own Data Leak Site (DLS: personal site of cybercriminals where the victims of attacks are announced to the public) and, in the case of encryption of systems through the use of ransomware files, by blocking victim’s business operativity.

To withdraw the threat of publication and regain access to company data by restoring the impacted systems, cybercriminals often demand the payment of a ransom in cryptocurrency, after which it would be possible to re-establish a situation of operational normality for the victim company.

In the specific case that will be dealt within this article, in anonymized form, we will illustrate a case in which some particularly important logs were unavailable, limiting the possibility of reconstructing the events, addressing an issue which subsequently received feedback from the vendor, leaving a smoky veil behind the exploitation activities carried out by the threat actor while it was impossible to precisely define the vulnerability exploited by the cybercriminals.

It should also be noted that some evidences, within the body of the article and in the images inserted, will be censored with “[redacted]” or asterisks and blurred, in order to avoid any traceability to the victim of the attack.

The case analyzed

This is the case of the exploitation of a vulnerability relating to Zyxel devices, which, once exploited, allowed the threat actor to obtain administrator access to the firewall console and to collect credentials, including those relating to the corporate domain, for subsequent reuse, allowing attackers to compromise the infrastructure.

This is confirmed, as well as by our analyses that we will illustrate in detail in the rest of the article, by the bullet-in released by the vendor Zyxel on September 3rd 2024, which can be consulted at the following link:

Zyxel USG FLEX and ATP series – Upgrading your device and ALL credentials to avoid hackers’ attacks – Zyxel Support Campus EMEA

The article, in which some necessary remediation actions are recommended at the corporate network level, urging the immediate update of the operating system of the Zyxel device to the latest available versions, asserting that the vulnerability was present and exploited in previous versions and that following the update those devices would no longer be affected, was published in a date after we performed our analysis aimed at identifying the entry point exploited by cybercriminals during a cyber-attack on a victim company.

Within the article, some corresponding Indicators of Compromise (“IoCs”: Indicators of Compromise) are identified for users of Zyxel devices, corresponding on several occasions, in which the attackers have operated identically also using the same nomenclature for the users created in order to maintain persistent access to the infrastructure, as well as a pattern in their modus operandi that repeats the exact same activities and in the same order.

Evidences detected

As part of our analysis activities, we detected a first access by cybercriminals in the second week of September, with the default “admin” user, coming from the IP address 178.249.211.103. Due to the low retention set and the lack of logs relating to previous dates resulting from it, it was not possible to identify the vulnerability exploited to get hold of the credentials used for access.

First access to the firewall console by the threat actor

 

The IP address used 178.249.211.103 was geolocated in Italy, as visible in the figure shown below (sources of the images: “talosintelligence.com” and “spur.us”). The peculiarity of its geolocation is important because it highlights an anonymization technique used by the threat actor, namely the use of a VPN service, “Mullvad VPN”, in order to hide the real origin of the traffic, appropriately positioning itself in the state of the victim company.

Geolocation of IP address 178.249.211.103 from “talosintelligence.com”
Evidence of Mullvad VPN being used from “spur.us”

 

During the campaign of cyberattacks that targeted Zyxel devices, cybercriminals have always chosen their geolocation appropriately to be in the same country as the attacked infrastructures, using VPN services.

In fact, they will repeat access to the firewall from the IP address 85.190.232.139 almost a month later, this time using the “NordVPN” service, making the traffic look like it was coming from Italy again.

Evidence of access to the firewall console by the threat actor
Geolocation of IP address 85.190.232.139 from “talosintelligence.com”
Evidence of Nord VPN being used from “spur.us”

 

Subsequently, the threat actor will proceed with new accesses on different days, creating the “SUPPOR87” and “vpn” users. As in similar cases relating to the same attack campaign, analyzed by Yarix but also by other professionals in the defense of infrastructures, users were in fact created on the firewall, useful for accessing again to then extend their control within the infrastructure. The same TTPs (TTPs: Tactics, Techniques and Procedures) were in fact used by the threat actor in various attacks, which is why it was possible for us to associate the attack in question with the ransomware group “Helldown”, a growing cybercriminal group on the rise.

“Helldown” ransomware group, as investigated by YCTI (Yarix Cyber Threat Intelligence) Team
Particularly active in August and October 2024, with more than 30 attacks reported between August and November 2024, the ransomware group “Helldown” is linked to the campaign of attacks which targeted Zyxel firewalls.
It is also known to have compromised the network of the vendor Zyxel during the summer of 2024,  exfiltrating 253GB of data. In the following article, by “Halcyon”, you can learn more about the events mentioned:
Zyxel Networks hit by helldown ransomware, 253gb data leaked
The group has developed variants of its ransomware that are compatible with both Windows and Linux, allowing them to target a wide range of infrastructures. It is also known to adopt a double extortion strategy, exfiltrating large amounts of sensitive data and threatening to publish it on its Data Leak Site (DLS) if the ransom is not paid. According to what has been observed on the group’s DLS, a minimum of 22 GB of data up to a maximum of 431 GB are exfiltrated. This modus operandi deviates from the strategy commonly adopted by other ransomware groups, which tend to favor a more selective and targeted exfiltration in order to maintain a discreet profile and optimize the impact of any disclosure. Additionally, its ransomware, analyzed in different occasions by cybersecurity professionals, is equipped with advanced anti-debugging measures and manipulates system processes, making detection more difficult and complicating recovery efforts. For example, recent incidents have seen how Helldown completely removes the tools used during the compromise, as well as overwriting the free hard disk space on different machines in order to hinder the recovery process and reduce the effectiveness of file carving.

In the case presented in this article, we analyzed the accesses which led to the actual attack in which the systems were encrypted, finding that during these accesses, the threat actor used the IP address 193.37.32.55 and more generally speaking IP addresses of the same subnet 193.37.32.0/24.

Evidence of the creation of local user “SUPPOR87” on the firewall by the threat actor
Evidence of the creation of local user “vpn” on the firewall by the threat actor

 

Again, the cybercriminals used a VPN anonymization service, namely “Express VPN”, but this time geolocating themselves in Singapore.

Geolocation of IP address 193.37.32.55 from “talosintelligence.com”
Evidence of Nord VPN being used from “spur.us”

 

After the creation of the users, accesses were detected from the following IP addresses, as mentioned above, belonging to the same subnet.

– 193.37.32.74
– 193.37.32.92
– 193.37.32.73
– 193.37.32.68
– 193.37.32.55
– 193.37.32.94
– 193.37.32.97

 

Evidence of the firewall login events by the threat actor, from IP addresses of 193.37.32.0/24 subnet

 

The lack of logs relating to VPN accesses, unavailable due to the short retention set, made it impossible in this case to have clarity on the concomitance of VPN accesses in correspondence with firewall accesses, however it was possible to identify the use of VPN technology for remote access to the infrastructure through correlation of evidences.

In the system artifacts obtained from the domain controller server of the infrastructure, in fact, it was possible to detect accesses to the same server, first as network accesses (Logon Type 3) and then via Remote Desktop Connection (using RDP protocol), coming from the IP address of the gateway, i.e. the perimeter firewall, allowing us to identify it as an initial access point exploited by attackers.

An additional IoC present on several occasions, in the analyzed attacks related to the same campaign, was the hostname of the machine used, i.e. “ALICE43E9”.

{“EventData”:{“Data”:[{“@Name”:”SubjectUserSid”,”#text”:”S-1-0-0″},{“@Name”:”SubjectUserName”,”#text”:”-“},{“@Name”:”SubjectDomainName”,”#text”:”-“},{“@Name”:”SubjectLogonId”,”#text”:”0x0″},{“@Name”:”TargetUserSid”,”#text”:”S-1-5-21-975385272-408449264-2835695090-500″},{“@Name”:”TargetUserName”,”#text”:”Administrator”},{“@Name”:”TargetDomainName”,”#text”:”*****”},{“@Name”:”TargetLogonId”,”#text”:”0x12EEAC4E”},{“@Name”:”LogonType”,”#text”:”3″},{“@Name”:”LogonProcessName”,”#text”:”NtLmSsp “},{“@Name”:”AuthenticationPackageName”,”#text”:”NTLM”},{“@Name”:”WorkstationName”,”#text”:”ALICE43E9″},{“@Name”:”LogonGuid”,”#text”:”00000000-0000-0000-000000000000″},{“@Name”:”TransmittedServices”,”#text”:”-“},{“@Name”:”LmPackageName”,”#text”:”NTLM V2″},{“@Name”:”KeyLength”,”#text”:”128″},{“@Name” :”ProcessId”,”#text”:”0x0″},{“@Name”:”ProcessName”,”#text”:”-“},{“@Name”:”IpAddress”,”#text”:”192.168.50.254″},{“@Name”:”IpPort”,”#text”:”0″},{“@Name”:”ImpersonationLevel”,”#text”:”%%1833″},{“@Name”:”RestrictedAdminMode”,”#text”:”-“},{“@Name”:”TargetOutboundUserName”,”#text”:”-“},{“@Name”:”TargetOutboundDomainName”,”#text”:”-“},{“@Name”:”VirtualAccount”,”#text”:”%%1843″},{“@Name”:”TargetLinkedLogonId”,”#text”:”0x0″},{“@Name”:” ElevatedToken”,”#text”:”%%1842″}]}}

Evidence of network access on the domain controller server by the threat actor using “ALICE43E9”
Evidence of Remote Desktop Protocol (RDP) connection being established by the threat actor

 

As visible, the access to the Domain Controller was made with the user “Administrator” from the IP address of the gateway (firewall): this indicated the use of a VPN. It is possible, as noted in other attacks of the same campaign, that by the initial compromise of the firewall the cybercriminals leveraged the domain controller’s LDAP synchronization to then move laterally inside the devices within the network, as the common peculiarity within the campaign’s attacks revealed to be the use of firewalls as access points for IPsec VPNs by the victim companies, as in the case we analyzed.

We detected also that some policies have been added in between the firewall’s ACLs (Access Control Lists) to allow traffic from any source to any destination (ANY -> ANY), called “Policy-Control_TWU”.

Evidence of firewall policies added by the threat actor

 

To make lateral movements, the threat actor then proceeded by using a powershell command to download a network scanning tool, namely “Advanced IP Scanner”, renaming it to “i.exe”.

Evidence of powershell command executed to download “Advanced IP Scanner”, renaming it in “i.exe”

 

The actual creation of “i.exe” on the server was evident within the server artifacts, in fact during the analysis it was possible to notice the presence of the file within the context of the “Administrator” user and also of its executions.

Evidence of the presence of “i.exe” on the domain controller server

 

“Advanced IP Scanner” is a legitimate tool for systems discovery within the network to which the user is connected, often used by cybercriminals after obtaining abusive access to infrastructures in an attempt to identify possibilities of lateral movements on other hosts on the network.

Evidence of the executions of “i.exe” and “advanced_ip_scanner.exe” on the domain controller server

 

Next, the threat actor transported the ransomware file for the ESXi servers, namely “enc-esxi”, inside the domain controller (DC) server. From here, it will then authenticate to the ESXi server and proceed with the encryption activities.

Evidence of the creation of “enc-esxi” ransomware file on the domain controller server

 

During the incident we analyzed, we were able to detect the use of three (3) ransomware files, two of which intended for the encryption of Windows operating systems and the last, the linux variant, intended for the encryption of ESXi operating systems.

In fact, the lateral movement on the ESXi server happened shortly after via OpenSSH. This is detected on the source system of the connection, by identifying the execution of OpenSSH detected in the domain controller’s (with IP address 192.168.50.245) system artifacts.

Evidence of the execution on “OpenSSH\ssh.exe” on the domain controller server

 

The connection is also detected on the recipient system, within the logs of the ESXi server (some of which remained partly unencrypted), where the threat actor accessed with the “root” user.

Evidence of the SSH connection by the threat actor from the ESXi server logs

Encryption and credential access

Once connected to the ESXi server, the threat actor performed a copy of the “enc-esxi” ransomware file via SCP (Secure Copy Protocol, a protocol that allows file transfer among its functions) and then assigned the correct permissions so that it can be executed, with the “chmod” command.

Evidence of the command “chmod” executed to change permissions to “enc-esxi” file on the ESXi server

 

What we found shows a particular difference between what we analyzed and what was found in other attacks of the same campaign, namely the insertion of manual commands directly from the threat actor on the ESXi server.

In addition, the activities of the threat actor included the elimination of the ransomware files from the systems, preventing the analysis of the code by our Team.

By reconstructing the chain of events, we were also able to detect the use of Mimikatz for credential theft activities on one of the servers of the infrastructure.

Evidence of the creation of “mimikatz.exe” on the domain controller server

 

“Mimikatz” is an open source HackTool, widely used by attackers to perform various privilege escalation activities, collecting credentials to extend their control within the attacked infrastructures.

The second detected ransomware file, the “e_win.exe” file, was then transferred.

Evidence of the creation of “e_win.exe” ransomware file on the domain controller server

 

The ransomware file in question, upon its execution encrypted the data contained in the system and within the active network shares, applying the extension “.locklocklock” to the impacted files and releasing the ransom note named “Readme-locklocklock.txt”, with the following content:

Your data are stolen and encrypted.
If you want to restore your files, you need pay ransom to get your files unlocked.
We will publish your files on onion websites if you don’t pay the ransom.
If you want to avoid this attacking happened again, we can offer you the security report.
Don’t turn off your servers if you see the note, or the files will be damaged forever.
Contact us on qtox:
qTox ID: 0DA1273FB[REDACTED]9C3ADAE7A9.
If qTox doesn’t work, send email to: unitui57@onionmail.org.
Tell us the encryption ID when contact us.
Your encryption ID is: *****.

Within the ransom note, there was the qTox contact indicated by the threat actor (qTox ID 0DA1273FB[REDACTED]9C3ADAE7A9) to start a negotiation on the payment of the demanded ransom and an email address commonly seen within the attacks of the same campaign, namely “unitui57@onionmail.org”.

In both usable channels, the communications are encrypted in such a way that they do not reveal the real location of the TA.

Subsequently, the threat actor proceeded to transfer an additional ransomware file for Windows operating systems within the domain controller server, namely the “LB3.exe” ransomware file, based on variants of the well-known Lockbit ransomware group.

Evidence of the creation of “e_win.exe” ransomware file on the domain controller server

 

Upon its execution, the ransomware file encrypted the data on the Windows system and on the active network shares, applying a random extension and releasing the ransom note whose name included the random extension followed by “. README.txt”, with the following content:

Your data are stolen and encrypted.
If you want to restore your files, you need pay ransom to get your files unlocked.
We will publish your files on onion websites if you don’t pay the ransom.
If you want to avoid this attacking happened again, we can offer you the security report.
Contact us in qtox.
qTox ID: 0DA1273FB[REDACTED]9C3ADAE7A9.
If qTox doesn’t work, send email to: unitui57@onionmail.org.

Again, the same channels were proposed to get in contact with the cybercriminals and to start the negotiation.

Before proceeding with the encryption activities, the threat actor manually executed commands on the ESXi server with iterative instructions to identify and kill the active VMs processes, in particular by executing the following command:

“For i in ‘esxcli VM Process List | grep “World ID” | awk ‘{print $3}”; do esxcli vm process kill -t=force -w=$i;done;”

Further commands were then executed manually by the threat actor, which for completeness we will detail:

2024-10-04T21:50:02Z shell[4376006]: [root]: esxcli vm process list
2024-10-04T21:50:09Z shell[4376006]: [root]: nohup /tmp/enc-esxi /vmfs/volumes 1>/dev/null&
2024-10-04T21:50:15Z shell[4376006]: [root]: ps -Tcjstv | grep tmp
2024-10-04T21:51:26Z shell[4376006]: [root]: rm -rf /.ash_history /tmp/enc-esxi
2024-10-04T21:52:49Z shell[4376006]: [root]: cd /vmfs//volumes/
2024-10-04T21:52:50Z shell[4376006]: [root]: ls
2024-10-04T21:52:56Z shell[4376006]: [root]: ls Datastore1/
2024-10-04T21:53:12Z shell[4376006]: [root]: ls Datastore1/*****
2024-10-04T21:53:29Z shell[4376006]: [root]: ls *****
2024-10-04T21:53:56Z shell[4376006]: [root]: ls -al Datastore1/*****
2024-10-04T21:54:15Z shell[4376006]: [root]: du -hs Datastore1/*****
2024-10-04T21:54:31Z shell[4376006]: [root]: ps -Tcjstv | grep tmp
2024-10-04T21:54:33Z shell[4376006]: [root]: ps -Tcjstv | grep tmp
2024-10-04T21:54:35Z shell[4376006]: [root]: ps -Tcjstv | grep tmp
2024-10-04T21:54:50Z shell[4376006]: [root]: rm -rf /.ash_history
2024-10-04T21:54:56Z shell[4376006]: [root]: ls /tmp

Detailing the commands we switched the names of the involved servers with “*****” to avoid any reference to the victim of the attack.

Below is an in-depth analysis of the commands executed by the threat actor, specifying in detail the purpose of the commands and the parameters used:

  1. esxcli vm process list

Command executed to get the list of active VMs.

  1. nohup /tmp/enc-esxi /vmfs/volumes 1>/dev/null&
  • nohup: prevents a process from being terminated when the terminal session is closed
  • /tmp/enc-esxi: executes the ransomware file from the “/tmp/” path
  • /vmfs/volumes: this is the directory containing the datastores, on which the threat actor wanted to run the ransomware file
  • 1>/dev/null: Redirects the standard output of the command to the null device.
    This part has the function of ignoring the output
  • &: puts the command in the background

Then, the command started the ransomware file in the background without showing the output, even if the terminal is closed.

  1. ps -Tcjstv | grep tmp
  • ps: shows the list of running processes
  • -T: Shows the threads of each process
  • -c: displays the names of the reduced commands
  • -j: shows the process tree with additional information, such as sessions and groups
  • -s: lists processes per session
  • -t: restricts the output to the specified terminal
  • -v: Provides additional details about memory usage
  • | grep tmp: filters the output to show only the processes related to the string “tmp”

This command searched for running processes associated with files or executables located in the /tmp directory.

  1. rm -rf /.ash_history /tmp/enc-esxi
  • rm: delete files or directories
  • -r: delete recursively (required for directories)
  • -f: force deletion without confirmation
  • /.ash_history: is the file that stores the history of commands used in the ash shell (a lightweight shell used on some systems)
  • /tmp/enc-esxi: the file to be deleted, i.e. the ransomware file

This command therefore deleted the command history and the ransomware file on the ESXi server.

  1. Navigating the File System

The following commands were then executed

2024-10-04T21:52:49Z shell[4376006]: [root]: cd /vmfs//volumes/
2024-10-04T21:52:50Z shell[4376006]:[root]:ls
2024-10-04T21:52:56Z shell[4376006]: [root]:ls Datastore1/
2024-10-04T21:53:12Z shell[4376006]: [root]: ls Datastore1/*****
2024-10-04T21:53:29Z shell[4376006]: [root]: ls *****
2024-10-04T21:53:56Z shell[4376006]: [root]: ls -al Datastore1/*****
2024-10-04T21:54:15Z shell[4376006]: [root]: du -hs Datastore1/*****

to move around by exploring the file system.

  1. Repeated process checks and cleaning
  • ps -Tcjstv | grep tmp (repeated several times): checks the status of processes associated with /tmp, probably to check the execution of the ransomware
  • rm -rf /.ash_history: Removes command history again
  • ls /tmp: Shows the contents of the /tmp directory, to verify that the ransomware file has been deleted from it

Once the threat actor had manually executed the ransomware files on the ESXi server and on the Windows servers, it proceeded to terminate the connections to the infrastructure.

Due to the reachability of the servers backup files via network shares, these were also encrypted using the ransomware for Windows systems.

Our Team has therefore, in alignment with the IT Team of the attacked company, gradually proceeded to restore the resources necessary for operational recovery, allowing the restart of business once the recommended remediation actions were applied to minimize the risks of new compromises.

Nevertheless, during our analysis we focused particularly on the search for evidences of exfiltration activities, which the threat actor used to perform in other attacks of the same campaign. In this case, no indicator was identified that could suggest an exfiltration activity. In addition, no reference to the company that was the victim of the case we analyzed was published on their DLS, confirming that our analysis had been completed correctly.

IOCs (Indicators of Compromise):

  • Network:
    • IP C2
      • 178.249.211.103
      • 85.190.232.139
      • 193.37.32.97
      • 193.37.32.55
      • 193.37.32.94
      • 193.37.32.68
      • 193.37.32.73
      • 193.37.32.92
      • 193.37.32.74
  • Hostname of the device used by the threat actor:
    • “ALICE43E9”
  • Name of the ACLs inserted in the firewall configuration:
    • “Policy-Control_TWU”
  • “e_win.exe” Ransomware file:
    • Extension applied to files: “.locklocklock”
    • Ransom Note Name: “Readme-locklocklock.txt”
    • Ransom Note Hash (Sha256): 4ac8b5edd679c54ed5ffa3f1403e13322a175e25020c5211f6b23630f3feb4de
  • “LB3.exe” Ransomware file:
    • Name: “LB3.exe”
    • MD5 hash: 2630663a9f73a85a77fbff918d402bdc
    • SHA1 hash: f8aac544bde705a9a4e0e086a107d1200e045dd0
    • SHA256 hash: 965047b2f573f732c66824cba2dda2309b9e8e36b74d315d845a0138fed705a6
    • Extension applied: “.*randomic*”
    • Ransom Note Name: “*randomic*. README.txt”
    • Ransom Note Hash (Sha256): 95d26fea78a10ee5d82d4de5e16bba8077ef038139b3c0fcf7519f2b4c813518

 

Helldown TTPs (Referencing MITRE ATT&CK®):

Initial Access (TA0001):

  • T1190 – Exploit Public-Facing Application (Zyxel Firewall)
  • T1078.001 – Valid Accounts: Default Accounts

Execution (TA0002):

  • T1053.005 – Scheduled Task/Job: Scheduled Task
  • T1059.004 – Command and Scripting Interpreter: Unix Shell

Persistence (TA0003):

  • T1136.001 – Create Account: Local Account

Privilege Escalation (TA0004):

  • T1078.001 – Valid Accounts: Default Accounts
  • T1078.002 – Valid Accounts: Domain Accounts
  • T1098 – Account Manipulation

Defense Evasion (TA00005):

  • T1070.004 – Indicator Removal: File Deletion

Credential Access (TA00006):

  • T1003 – OS Credential Dumping (Mimikatz)

Discovery (TA0007):

  • T1018 – Remote System Discovery

Lateral Movement (TA0008):

  • T1021.001 – Remote Services: Remote Desktop Protocol
  • T1021.002 – Remote Services: SMB/Windows Admin Shares
  • T1570 – Lateral Tool Transfer

Command and Control (TA0011):

  • T1105 – Ingress Tool Transfer

Impact (TA0040):

  • T1486 – Data Encrypted for Impact
  • T1490 – Inhibit System Recovery

Author

Claudio Vozza is an Incident Responder and member of the YIR Team (Yarix Incident Response Team). His broad knowledge is a result of dedication, experience and continuous drive. Led by passion and great attention to details, his perfected abilities of carrying out detailed analysis on small to large infrastructures and of correlating different elements and evidences based on his own unique point of view, has helped him and the YIR Team in managing and solving many cyber incident cases, maintaining calmness even under stress circumstances. He has recently started taking part at cybersecurity focused events as a speaker and has a wide variety of incident responses managed, ranging from companies to public institutions.

Share this post

Back to Posts