Analysis and Reverse Engineering of a Banking Trojan Malware from the Zeus Family

Juan M. R.
01/02/2022
Reversing
Table of Contents show

1. Introduction and Objectives


In this article, we will demonstrate how to conduct a reverse engineering analysis of a banking trojan from the Zeus family.

For our study, we have been provided with a single binary file named “fichero.bin.” You can download it from the JMSec GitHub repository:

To undertake a study of this nature, you’ll need some basic knowledge of reverse engineering.


2. Setting Up the Laboratory and Description of Materials


To begin the exercise, it should be noted that the analysis of the binary is conducted under the Windows 10 operating system. The following list enumerates the tools and files that will be necessary for the successful completion of the exercise:

A brief description of each tool:

  • “fichero.bin”: This is the binary to analyze.
  • IDA Debugger: We will use it to perform static analysis of the binary.
  • Editor HTML: It will be necessary to study or edit the resulting files from unpacking the binary in an organized manner.
  • Apache Server: It will be necessary to upload the decompressed files to the web server and see how they are interpreted in the browser in order to perform subsequent inspections of the elements that make up the different banking websites. We could say that it is necessary for conducting dynamic analysis.
  • Offzip: A very useful tool for unpacking data contained in various types of files, such as raw files, zip packages (zlib/gzip/deflate), “zip” files, executables, and more. By using the helpful search option “-S,” it can scan the file for subsequent decompression. After unpacking, the files can be automatically dumped with an extension, which can be helpful for quick identification. It’s worth noting that this tool is similar to “binwalk.”


  • Zlib: It’s a data compression library, open-source and cross-platform. It provides an implementation of the DEFLATE algorithm used in the “gzip” compression program.

3. Analysis of the binary’s packaging


The binary “fichero.bin” presents a series of complications that are difficult to interpret from the perspective of a common malware analysis, as its analysis involves a packaging technique that initially appears unfamiliar and challenging to decipher.

a) Reconnaissance Phase


The provided binary is not a proper executable file, so if we try to operate it with tools like “Immunity Debugger” or “OllyDebugger,” it gives us the following error:



If we try to open it with “Resource Hacker,” we also get an incorrect result:



As we can see from the errors obtained, it’s not an executable file. Similarly, if we try to open it with “Dependency Walker” or “w32dasm“, we get the same results.

However, when we open it with our beloved “IDA Debugger,” we obtain the first positive results:




As we can see, the code is well packed and there’s no clear interpretation of the binary’s instructions. The other tabs (Exports, Imports, Names, Functions, etc.) don’t provide any useful results. The recognized strings or “strings” can be seen in the downloaded file:

If we interpret the character strings found throughout the binary, we can quickly conclude that it could potentially be a banking-related web page (indicated by phrases like “</body>” or “</script>”) intended for use in Italy (given that it’s written in Italian). However, this conclusion is still far from being definitive.

At this point, we need to study the hexadecimal representation of the binary to draw conclusions about how to interpret it and understand its compression method in order to find the appropriate tool for unpacking it.

To determine the type of compression used in the binary, we utilize the tools “scalpel,” “foremost,” “dumpbin,” and “PEiD.” Unfortunately, the results do not meet our expectations, prompting us to gather more information to potentially identify a vector of attack for unpacking the binary.

We know that file compressors use compression methods based on known algorithms, leaving a “signature” in the header of the resulting compressed file. This signature is referred to as “magic numbers.” For instance, when a file is compressed using software that employs the “zlib” library, the header of the compressed file starts with the hexadecimal sequence 0x78 0x9C. To verify this, we can use the “offzip” tool. This information is exactly what we needed to know, as the file we are analyzing contains these “magic numbers” in its header, as shown in the following image:



b) Unpacking with the “offzip” tool


Let’s verify using the “offzip” tool that the binary is indeed compressed with zlib.
The commands we will use with “offzip” are as follows:

  • To determine if the binary is indeed compressed with zlib: “offzip -S fichero.bin 0 0”
  • To extract the zlib results into a folder named “output”: “offzip -a fichero.bin c:\output 0”
  • To dump the results into a single file, which is useful when dealing with fragmented files: “offzip -a -1 fichero.bin c:\output 0”
  • To analyze/retrieve the contents of the index table of the file: “offzip -S -x fichero.bin 0 0”

We verify the existence of “zlib” and the successful retrieval of compressed files using the previously detailed commands:

  1. “offzip -S fichero.bin 0 0”: We confirm that it is packed with “zlib” and we see that it informs us that there are “42 valid compressed streams found,” so we will later see how to extract 42 files resulting from the unpacking of the binary.


2. “offzip -a fichero.bin c:\output 0”: Unpacking and dumping results into the “output” folder.


Here we can see the 42 extracted files in the “output” folder:



3. “offzip -a -1 fichero.bin c:\output_unico 0”: As we can see, there is a significant fragmentation of files (42), so we use this command to consolidate all the unpacking results into a single file.


The result of the obtained file:



c) A brief explanation about the results and manual unpacking


At this point, a brief explanation is necessary to delve into the results obtained. We know that the presence of the “zlib” compression is specifically marked by “0x78 0x9c”:

  • ZLIB_MARKERS = [‘\x78\x9c’]

We have already seen the results provided by “offzip”:



Therefore, we can manually extract the different zlib-packed fragments using the IDA hex editor by searching for the sequence 0x78 0x9C, as demonstrated below:



As we can see, if we compare the results obtained by “offzip” and those obtained by IDA, the presented addresses are exactly the same: (00fa, 01fd, 0234, 026f, 0f4b…). In this way, we can manually extract the zlib-packed data fragments to manipulate them at our discretion and identify the different parts that make up the binary. However, we use “offzip” to automate the process and unpack the binary.


4. Static analysis of the files obtained after unpacking


Having clarified the procedure for discovering the presence of “zlib” for the subsequent unpacking of the binary, we continue with the analysis of the obtained files.

a) Static analysis based on the unified file “000000fa.htt”


Let’s start with the unified file “000000fa.htt”. We’ll analyze it using IDA and the HTML Editor to see the results:




If we carefully analyze the “strings” found with IDA, we can observe that the programmer of this binary put a lot of effort into redirecting us to a specific IP address (209.85.229.104) when attempting to visit a list of websites of special interest related to global malware fighting and software updates, such as:

bitdefender.com, trendmicro.com, update.avg.com, pctools.com, secure.lavasoft.com, virustotal.com, avira.com.au, nortonantiviruscenter.com, www.zonealarm.com, anti-spyware.com.au, virusscan.jotti.org, virscan.org, kaspersky.co.uk, among many others.



With a brief analysis of the IP address 209.85.229.104, we can confirm that it corresponds to the well-known search engine “Google.”




If we enter the mentioned IP address into a web browser, we can confirm that it indeed corresponds to the “Google” website.



Having reached this point, we can now conclude that the binary is attempting to prevent us from connecting to the main cybersecurity and governmental websites (*.gov) by performing DNS redirection, specifically redirecting us to the “Google” website.



Now we will focus on the following strings within the binary:



Reading from the bottom to the top, we can see the attacker’s interest in “facebook” or “microsoft,” well-known sites for any malware developer due to the possibilities/advantages they offer when looking for an infection vector (to distribute the malware).

Continuing the reading, we can observe the attacker’s interest in executing the command “ipconfig /all” to gather information about the victim’s network configuration (IP addresses, gateway, network card type…). Additionally, they are also interested in the “net view” command to identify the devices (computers, printers, other shared resources) within the victim’s Local Area Network (LAN).

Based on the use of these commands, we can conclude that the binary is intended for use on Windows operating systems. An attacker (or intelligent malware programmed for this purpose), armed with the gathered data from within the victim’s machine and with the necessary privileges, could potentially cause significant damage to an organization. By identifying shared resources within the same LAN, they could distribute the malware to other machines, thereby infecting the entire internal network.

Regarding the web addresses at the top of the recognized strings, we can see that all of them employ the “wordpress” technology. In terms of current activity, only one of these addresses remains active as of today:

  • http://www.yalchin.com/

(The remaining domains either do not exist or are up for sale.)

However, the real significance of this set of web addresses lies in their structure: “www.xxx.com/../../.. /instal/file.php|file=profi.bin”.

By studying the structure “file.php|file=profi.bin,” we can deduce that it’s a remote call to a configuration file (“profi.bin”) similar to what some Trojans, like the famous “ZeuS,” use.

Here are some screenshots of the usage of this configuration file obtained from “ZeuS Tracker”:



Other similar structures as described above are present in some malwares but serve a different purpose. They involve making a system call (similar to the “start” command in Windows) that simultaneously executes/installs the binary file while also visiting a website to “mask” the malicious process in the background.

Here’s a demonstration of running a web page and an executable to show how the web page executes and appears on the screen in the foreground, while the binary is dumped into the system in the background (this also depends on how the binary has been programmed, of course).



Here we can see how the command “start http://localhost/trojanweb.php|Bicharraco.exe” first opens the specified web page in the system’s default browser and simultaneously executes the binary in the background, directly dumped into the command line (cmd.exe).

Continuing with the analysis of the binary, once unpacked, we encounter small hexadecimal sections that we need to process, such as:



Once this conversion is done with all the affected strings and having cleaned the “web” code of impurities, the source code to analyze looks as follows:




But this only gives us a global view of what the binary does, so if we really want to delve deeper and understand what the attacker is up to, we must carefully analyze the fragmented codes obtained with “offzip” part by part. Therefore, we proceed to the analysis of the most important files obtained from the unpacking of the binary.


b) Static analysis by discrimination of files obtained after unpacking





The conclusion we draw from this analysis is that it appears to be a website designed to mimic “Deutsche Bank’s” interface. It sends a message to the victim, urging them to click on a link that supposedly directs them to their account balance or to proceed with a “restitution” to return the alleged overcharged money. The victim would be redirected to the “goToTransfer” link, leading to another web page where they are prompted to input all the necessary information for a bank transfer using the “Bonifici SEPA” (Single Euro Payments Area) system. The attacker anticipates that the victim would assume the funds were mistakenly deposited into their account and would be prompted to transfer the estimated amount back. The term “bonifici” signifies a bank operation that authorizes the transfer of funds from one current account to another.



  • In the “0000a09d.txt” file, we can observe how the following message is presented to the user:



After the message, the fields that are loaded request user credentials, including username and password, among others:



And upon completing all the fields as requested by the website with its message “Vi preghiamo di compilare tutti i campi,” it takes us to the following message:




However, if all the fields are not filled correctly, it leads us to an error message that asks us to fill in the necessary fields correctly:



For this, it triggers an “alert()” that pops up on the screen asking to fill in all the fields:



In this file, the defined variable “_0xf6fa” also draws our attention, as its content is entirely in hexadecimal. If we want to know what it hides behind those values, we’ll need to convert it to ASCII:



Converted to ASCII, it looks like this:



As we can see, they are strings of special interest used by the binary, and they will be present throughout the entire analysis, as we can find the same hexadecimal code in many of the fragmented files. As we progress in the analysis, we will comment on each of the obtained strings.

But the analysis of this file is not over yet, as we can see something very important in the middle of the code that we need to process to understand what it is.

If we observe carefully, we can see that in the middle of the code, there are some “javascript” instructions that we need to analyze thoroughly. Moreover, this piece of code is present in most of the fragmented files that we will analyze later on:



We can see that it refers to several web addresses. If we go to http://download.macromedia.com/pub/shockwave/cabs/flash/swflash.cab and download “swflash.cab,” we can see that when we decompress it, it contains a self-extracting executable and an information configuration file (“.inf”) that contains instructions within it:



Later in the code, we see the website to download “Flash Player” from http://www.macromedia.com/go/getflashplayer. If we continue reading, we can see a call to the address http://nfriedly.github.com/Javascript-Flash-Cookies/storage.swf:



To gather more information about this website, we go to the link at the bottom right (http://www.nfriedly.com/techblog/2010/07/swf-for-javascript-cross-domain-flash-cookies/) and see that it’s a project related to “cross-domain flash cookies.” No need to say more, as the intentions of the attacker with regard to this phenomenon are quite evident:



At this point, we can gather more information about the executable “FP_AX_CAB_INSTALLER64.exe” (obtained from the extraction of the “swflash.cab” file) by using online tools like ANY.RUN or VirusTotal (as it is not our purpose to analyze it in this exercise). These tools provide a detailed analysis with the following results:




Therefore, it is not surprising to see in the “Signatures” section that the executable gathers private information from browsers (such as history or cookies, as seen in “Summary Mutexes”) and is also configured to run at each Windows login.

It is quite likely that the information collected from browsers is stored in “storage.swf” and later accessed through the “Cross-domain Flash Cookies” web, as we’ve seen before. As it’s not our intention to analyze this executable in this exercise, we will conclude at this point. Continuing down this path would make the analysis of the original binary quite extensive.

Let’s proceed with the analysis of the “fragmented” files.

  • In the file “0000d245.txt,” we find a function that doesn’t have much to comment on, as its name suggests (“conferma”), its function is to perform a confirmation check that the fields have been filled correctly, and if not, it sends an error message.


  • In the file “0000ea4c.dat,” we can observe how a function is defined to load scripts (loadScript()) and another one to send the data previously entered by the victim to what appears to be the “command center,” administration, or control panel of the binary located at http://www.macgreccheckserving.net/securepanel/. This is achieved through the sendNumbers() function.


  • In the file “00001a01.dat,” we find a function responsible for the security of the foreign transfer operation. It prompts the user to enter a code from an image (“captcha”) to verify the authenticity of the operation.


  • In the file “00001c14.dat,” we can see how the victim is prompted to enter their PIN, and their connection details are provided as well.



As a general note, it should be mentioned that HB TOKEN is a small electronic device used for secure access to online banking. It generates a code that is intended to be used only at the moment when our access system requires it. Additionally, it does not need to be installed on the PC and has a predetermined lifespan indicated on the back of the device, as the analyzed message correctly states.

Continuing with the analysis, we can observe throughout the code how it anticipates the entry of a 10-digit PIN and the device’s password, followed by their subsequent sanitization.



In the following image, we can see how it checks whether the entered data is correct, and if not, it triggers an “alert” on the screen, notifying the user that they need to correctly enter the PIN in order to access their data:



We can also observe the same validation in the “0000374d.dat” file:



  • In the “000026c8.dat” file, we come across the “dogetdata()” function, where we see a reference to “pnlCruscotto,” which appears to be related to a “dashboard panel” (according to an approximate Italian translation). This panel might contain certain relevant data. Additionally, we can observe the usage of the “bancareale” logo from its own website: https://pr.bancareale.it/BRIO2/Images/logo_50.gif


  • In the “000061dd.opy” file, we find a reference to the “ingdirect” bank. It sends a message to the victim, requesting them to register their “TAN” card by verifying their data and password in the following manner:


  • In the “00002875.dat” file, we can see how the victim is requested to enter a 10-digit security code in order to proceed with the process, ensuring greater security. We can also observe that at the end of the file, the image of the “bancareale” bank is used:


  • In the “00003506.dat” file, we encounter an “input” form for the victim to enter the web application. The fields to be completed are for the username, password, and device.


Interpreted by a browser, it returns the following form:



  • In the file “00004038.dat,” we see that the victim is asked to enter an 8-character internet password. It performs a brief check, and if the password is not valid, it returns an error message saying that the password characters are not valid:


Subsequently, we can see that the image of “cartalis” is used from the address https://www.cartalis.it/Autenticazione/img/logo_cartalis.jpg for the entry of the requested 8-character password:






In the analysis of this message, it becomes apparent from the choice of vocabulary that the author is not exactly Italian, as in the first line they write: “La Poste Italiane ed il suo personale la vuole informare”; When in reality, since it’s plural, the correct phrasing should be “La Poste Italiane ed il suo personale la vogliono informare.” Additionally, at the end of the text, “Poste Italiana” is written, which is misspelled. The correct phrasing would be “Poste Italiane,” as “Poste” is plural and it’s a proper name.

Continuing to read the code, we can observe an error message and the module that the victim should fill out:






Studying the code, we can see that the “SECURITY CARD” consists of 24 numbers.

  • In the file “00013813.dat,” the image of the bank “atime” is used from the web address http://www.atime.it/img/logo.gif. As has been customary throughout the analysis, the following message is presented to the victim, which has been translated earlier:


Subsequently, the following messages can be seen, which have also been analyzed earlier:



At this point, we can conclude that we have analyzed the fragmented files obtained from the unpacking of the original binary. It is worth noting that the unpacked files that I haven’t mentioned in the analysis either contained the same information as other files I did mention, or their content didn’t provide any significant insights.


5. Conclusions


After analyzing the fragmented files, we can draw the following conclusions:

  • Firstly, after analyzing the first file (00000f4b.txt), we can conclude that it is a banking malware that seeks to use the victim as a mule. Supposedly, the user has received an erroneous financial transfer into their account and is coerced to return it to avoid reprisals. To do so, they are prompted to click on the “return the money” link, which leads them to a “bonifico SEPA” type transfer. This transfer will be configured to direct the transferred funds to the attacker’s account, which is unrelated to the account from which the erroneous transfer was made (likely a compromised account). This allows the attacker to gain funds from a compromised account, and law enforcement will face greater challenges in tracing the flow of money and apprehending the actual perpetrator.

  • We also observe how throughout the analysis, numerous banking websites are mentioned, using their logos, images, and forms. From this, we can deduce that it is a banking Trojan targeting a wide range of significant banks. For each of these banks, the Trojan prompts the victim to fill out a user data form, ostensibly to strengthen online security or to verify the user’s identity, or due to recent data losses in the system, among other pretexts. This way, the attacker gathers all the victim’s data. It’s worth noting that all the websites are in Italian, indicating that the targeting is focused on Italian-speaking victims. The affected banking websites are:

seg000:00059964 00000045 C dbonline.deutsche-bank.it/db/jsp/menuDbspa.jsp?randomseed=&lang=i*
seg000:000599B9 00000049 C dbonline.deutsche-bank.it/db/jsp/appInvoker.jsp?app=RETWNewMovementQue
seg000:00059A12 00000035 C dbonline.deutsche-bank.it/db/jsp/genericHandler.js
seg000:00059A57 00000047 C dbonline.deutsche-bank.it/db/jsp/appInvoker.jsp?app=RETWBonificoSepa
seg000:00059AAE 0000003D C dbonline.deutsche-bank.it/db/jsp/ecdlHandler.jsp?pageTo=mio seg000:00059AFB 00000031 C https://hbnet.cedacri.it/CreateDocument&Login
seg000:00059B3C 00000030 C https://bancopostaimpresaonline.poste.it/bpiol*
seg000:00059B7C 0000001A C https://.bancareale.it/
seg000:00059BA6 00000023 C https://pr.bancareale.it//WfHome
seg000:00059BD9 0000001A C https://hb.bancareale.it*
seg000:00059C03 00000023 C https://hb.bancareale.it/Bonifico*
seg000:00059C36 00000012 C http://gbw.it
seg000:00059C58 0000003B C http://linksimprese.sanpaoloimi.com/pmiweb/LoginServlet*
seg000:00059CA3 00000017 C http://webanking.it*
seg000:00059CCA 00000039 C http://webanking.it/htdocs/_websitelogin_nocert.html
seg000:00059D13 00000025 C https://core.cedacri.it//LogonStep
seg000:00059D48 00000012 C monetaonline.it
seg000:00059D6A 0000002D C cartalis.it/AuthenticationDelegatedServlet
seg000:00059DA7 0000000F C unicredit.it
seg000:00059DC6 0000001D C unicredit.it/nb/itwelcome*
seg000:00059DF3 0000004D C https://bancopostaonline.poste.it/bpol/cartepre/servizi/cartapostepaysaldo
seg000:00059E50 00000056 C https://bancopostaonline.poste.it/bpol/cartepre/servizi/cartapostepaylistamovimenti
seg000:00059EB6 0000001D C bancagenerali.itlogincid
seg000:00059EE3 0000002C C https://www.bancagenerali.it/fec/logincid
seg000:00059F1F 00000022 C https://www.bancagenerali.it/fec*
seg000:00059F51 00000025 C https://secure.ingdirect.it/Welcome*
seg000:00059F86 0000001F C https://.csebo.it/webcontoc/
seg000:00059FB5 00000025 C https://www.csebanking.it/fec/login*
seg000:00059FEA 0000001C C bancamarche.itattenzione*
seg000:0005A016 00000022 C https://.bancamarche.it/webbdm/
seg000:0005A048 00000032 C https://www.isideonline.it/relaxbanking/sso.Logi*
seg000:0005A08A 00000036 C fideuramonline.it/script/LogonServlet?function=logi
seg000:0005A0D0 0000003B C ://hb.mps.it/PaschiHome/LOGIN2.0/RTLOGIN/ASPX/RTLogin01.
seg000:0005A11B 00000020 C hb.mps.itRTLoginToken01.aspx*
seg000:0005A14B 0000003E C ://hb.antonveneta.it/BAVIB/LOGIN2.0/RTLOGIN/ASPX/RTLogin01.
seg000:0005A199 00000028 C hb.antonveneta.itRTLoginToken01.aspx*
seg000:0005A1D1 00000031 C http://www.credem.it/secure/Forms/LoginForm.aspx
seg000:0005A212 0000001D C http://www.atime.it/home.htm
seg000:0005A23F 00000045 C dbonline.deutsche-bank.it/db/jsp/menuDbspa.jsp?randomseed=&lang=i*
seg000:0005A294 00000049 C dbonline.deutsche-bank.it/db/jsp/appInvoker.jsp?app=RETWNewMovementQue
seg000:0005A2ED 00000035 C dbonline.deutsche-bank.it/db/jsp/genericHandler.js
seg000:0005A332 00000047 C dbonline.deutsche-bank.it/db/jsp/appInvoker.jsp?app=RETWBonificoSepa
seg000:0005A389 0000003D C *dbonline.deutsche-bank.it/db/jsp/ecdlHandler.jsp?pageTo=mio

  • To conclude, it can be stated that the binary fully aligns with the behavioral pattern of a banking trojan. When the victim attempts to access their online banking system, the webpage is modified in such a way that the personal data entered by the victim for authorization, login, or other operations is not sent to the bank, but instead to a remote control panel or administration server. Therefore, we can outline what happens as follows:
Based on all these conclusions, it can be affirmed that this is indeed a banking trojan with various banking interfaces, designed for systems running Windows OS.

Given the information we have, let’s investigate to determine the specific type of banking trojan involved. We can search based on encryption methods, functions presented, and behavioral patterns. Using this approach, we find two types of trojans from the Zeus family that share similar functions and behavioral patterns:
  • BOLETO: This trojan from the Zeus family has its configuration encrypted with a hardcoded 32-bit XOR key embedded within the trojan’s binary. The configuration is also compressed using the ZLIB compression algorithm.
  • CITADEL: Another variant from the Zeus family, more recent versions of Citadel include a built-in DNS redirection functionality. This feature prevents infected systems from connecting to major security-related websites and law enforcement agencies on a global level.

Based on the information provided earlier, we can now conclude that the analyzed binary is a variant of the Zeus banking trojan, which shares features with other Zeus variants such as Boleto and Citadel.

To conclude this analysis, I would like to display the logos and images of the banks that we have encountered throughout the analyzed code, in order to visually interpret the previously provided information. It’s worth noting that many of the bank URLs mentioned in the binary analysis have restricted access to their logos and images. As a result, we cannot directly access them from the links embedded in the binary.

https://dbonline.deutsche-bank.it/db/img/LOGO_DB_B5C9E3.gif

https://pr.bancareale.it/BRIO2/Images/logo_50.gif

https://www.cartalis.it/Autenticazione/img/logo_cartalis.jpg

https://online-smallbusiness.unicredit.it/ibx/web/menu/menutop/images/logo.gif

https://www.bancagenerali.it/fec/03075/img/logohead.gif

https://secureca.ingdirect.it/images/errore/errore_attenzionetipo1.png

https://www.fideuramonline.it/portal/web2/default/images/logo/logo_03296.gif

http://www.atime.it/img/logo.gif


6. How to avoid becoming a victim of a banking Trojan


Throughout the analysis, we have seen how a banking Trojan operates. However, in this section, we will provide some basic guidelines on how to avoid falling victim to one of these Trojans.

The following measures are suggested to be taken:

  1. Ensure that antivirus systems are properly installed, configured, and up-to-date, preferably using intelligent and state-of-the-art solutions.
  2. Implement a whitelist for accepted IP addresses and/or use VPN services for incoming connections to the company’s internal network.
  3. Conduct cybersecurity awareness training sessions for employees and top management within the company.

It’s important to emphasize that while all these measures are of great importance and complement each other, from a professional standpoint, the last measure is the most crucial of all. This is because, in most cases, both banking Trojans and other malware (such as ransomware) use social engineering, primarily phishing, as the main attack vector based on deceiving the victim user.


7. Conclusions


In this article, we have witnessed the potential danger posed by a banking Trojan due to its ability to manipulate victims through social engineering techniques, ultimately leading to the theft of banking credentials and unauthorized financial transactions.

The importance of adequately protecting computer systems, implementing strong security policies, and, above all, raising cybersecurity awareness among employees and management has become evident.

If you are interested in conducting cybersecurity awareness training for your company’s employees and management or in running controlled phishing campaign tests, please do not hesitate to reach out to us.

Furthermore, if you’re interested in acquiring introductory knowledge in ethical hacking, you can enroll in our basic ethical hacking course. If you prefer to delve into more advanced offensive cybersecurity skills, you can explore our advanced course offerings.

Tags

National Institute of Cybersecurity (INCIBE) registered company

Spanish Cybersecurity Catalogue registered company

Privacy policy - Cookies - Legal terms
Contact
©2023 JAYMON SECURITY S.L. Copyright. All Rights Reserved.
Spain

No puedes copiar el contenido

Press enter to search or ESC to exit.