{
	"id": "16009136-142b-4133-9a6a-7e57655fb08f",
	"created_at": "2026-04-06T00:22:28.763682Z",
	"updated_at": "2026-04-10T03:24:18.171876Z",
	"deleted_at": null,
	"sha1_hash": "6d8967f37faf786759b2114fa15ff10bcd95e908",
	"title": "ELF Malware Analysis 101: Part 3 - Advanced Analysis",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 4066725,
	"plain_text": "ELF Malware Analysis 101: Part 3 - Advanced Analysis\r\nBy Avigayil Mechtinger\r\nPublished: 2021-02-17 · Archived: 2026-04-05 20:18:14 UTC\r\nGetting Caught Up to Speed\r\nSo far in this series we have profiled the ELF threat landscape and covered the most common intrusion vectors\r\nseen in Linux systems. We also pursued initial ELF analysis with an emphasis on static analysis. We learned about\r\nthe different artifacts and components that are relevant for initial analysis and how they can help us gather\r\nimmediate insights about a file. In Part 3, we will take the next step and dynamically analyze ELF malware.\r\nWhile static analysis is performed without execution, dynamic analysis gives us an understanding of how a file\r\ninteracts with the operating system at runtime. Insights about file behavior help us better assess the potential\r\nimpact of the malware and gather additional indicators that can help us paint the bigger picture (C\u0026C for\r\ninstance). Dynamic analysis also allows us to collect further Tactics, Techniques, and Procedures (TTPs) that can\r\nbe attributed to specific malicious tools and threat actors.\r\nStatic and dynamic analysis are complementary. The information gathered during initial analysis will accelerate\r\nthe dynamic analysis process.\r\nAgenda\r\nAfter reading this article you will be able to understand which insights can be extracted during ELF runtime and\r\nwhat tools can help you do so.\r\nThe following subjects will be covered in this article:\r\n1. Linux Processes\r\n2. ELF Syscalls\r\n3. Persistence Methods\r\n4. Network Sniffing\r\n5. Sandboxes\r\nAfter covering our dynamic analysis toolset, we will put them to use by practicing on a real sample found in the\r\nwild.\r\nAnalysis Environment Preparations\r\nBefore we get started, let’s prep your Linux VM (virtual machine). If you don’t have a Linux VM, follow this\r\nguide to install one.\r\nhttps://www.intezer.com/blog/malware-analysis/elf-malware-analysis-101-part-3-advanced-analysis/\r\nPage 1 of 21\n\nNeedless to say, running malware should only be done in isolated environments such as VMs. Even when using a\r\nVM the malware can cause harm, not only to your system but also to other machines over the internet. For\r\nexample, running a worm can spread it over the network (see New Golang Worm Drops XMRig Miner on\r\nServers). Running ransomware or stealers can encrypt and/or collect information from your VM, including files\r\nlocated on the shared folders with your host.\r\nMake sure that before you run a malware your virtual environment meets the following criteria:\r\n1. Your machine host name and user name are generic. Run uname  -n to see the host name of your\r\nmachine, and run getent passwd {1000..60000} to list all human usernames on the machine.\r\n2. Your IP is not easily trackable. Blurring your public IP can be done in several ways:\r\na. Basic: Use a VPN service on your host machine during dynamic analysis. The traffic from your VM\r\nshould be tunneled through your host. Verify your public IP from within the VM by running a\r\ncommand such as: curl ‘https://api.ipify.org’. There are various free VPN programs you can use\r\nsuch as OpenVPN.\r\nb. Advanced: Use a second VM as a router that tunnels traffic, via Tor for instance. Establishing that,\r\nyou can route the entire network from your malware analysis VM through the router VM.\r\nNote that you can always disconnect your machine from the internet and start the dynamic analysis with no\r\nnetwork connection as a first step.\r\n3. Your machine is clean from private information. Make sure that you don’t have any passwords, API\r\nkeys, etc. written on the machine.\r\n4. Disable shared folder and shared clipboard before running the malware.\r\nSetting Up SSH Connection\r\nUse SSH to transfer files from your machine (host) to your VM (guest). Follow these steps to establish\r\nconnection:\r\n1. Install OpenSSH on your VM:\r\nsudo apt-get update\r\nsudo apt-get install -y  openssh-server\r\n2. Shut down your VM.\r\nhttps://www.intezer.com/blog/malware-analysis/elf-malware-analysis-101-part-3-advanced-analysis/\r\nPage 2 of 21\n\n3. 3. Go to Settings \u003e Network.\r\na. Adapter 1 should be set to NAT:\r\n3. a. Add a second adapter: Choose “Host-only Adapter” and apply changes.\r\n4. Go to Settings \u003e System \u003e Motherboard and make sure these entries are enabled:\r\nhttps://www.intezer.com/blog/malware-analysis/elf-malware-analysis-101-part-3-advanced-analysis/\r\nPage 3 of 21\n\n5. Start your VM and get the LAN IP address of the VM instance. Run ip addr show.\r\nhttps://www.intezer.com/blog/malware-analysis/elf-malware-analysis-101-part-3-advanced-analysis/\r\nPage 4 of 21\n\n6. 6. Make sure the OpenSSH service is active on the VM by running: sudo service ssh status.\r\n6. You should now be able to connect from your host to the guest machine via SSH. Using scp command you\r\ncan copy files and directories from your host machine to the VM. Run on your host:\r\nscp -r myhostpath VM-username@/path/to/whereyouwant/thefile\r\nLinux Processes\r\nEvery instance of a running program on the system is a process. Each process has its unique process ID. You can\r\nsee all of your processes by running ps aux. The ps command displays information about the process that ran at\r\nthe exact time you ran the ps command. To see an ongoing repetitive output use top.\r\nFigure 1: ps aux output\r\nThe proc Filesystem\r\nThe “proc” filesystem is a pseudo-filesystem provided by the Linux kernel. It provides an interface to kernel data\r\nstructures which includes information about all currently running processes. It will commonly be mounted under\r\nthe /proc directory. Each process has its own directory under /proc and the directory name is the process ID.\r\nTo get a better understanding of the proc directory, open two terminals on your Linux VM and run ping 8.8.8.8 on\r\none of them. On the second terminal, run pidof ping to retrieve ping’s process ID.\r\nhttps://www.intezer.com/blog/malware-analysis/elf-malware-analysis-101-part-3-advanced-analysis/\r\nPage 5 of 21\n\nLet’s review the process directory by browsing the /proc/PID directory and running ls. You can see that it has\r\ndifferent directories and files. All process directories share the same structure, filenames and directories. Figure 2\r\ndescribes the flow above.\r\nFigure 2: Retrieving ping’s process ID and the process directory content\r\nThe following are some interesting files that will be present under every process directory:\r\ncmdline – command line arguments that ran the file.\r\nstatus – process status in human readable form.\r\nmaps – memory maps regions and their access permissions.\r\nexe – symbolic link containing the pathname of the executed command. Attempting to open it will open the\r\nexecutable. Try running sha256sum exe and sha256sum on the ping file: sha256sum $(which ping). You will see\r\nthey match.\r\nAfter you kill the ping process, you will see the /proc/PID directory no longer exists.\r\nBrowse here for more information about the proc file system.\r\nProcess Tree\r\nThe process tree structure can give you insights about what is running on a machine before diving into specific\r\nprocesses.\r\nA single executable can create more than one process on the machine. Let’s emphasize that by using the pstree\r\ncommand to view the running processes as a tree. The following are some examples of what the process tree will\r\nlook like for each scenario:\r\n1. Other process creation: A process can call other processes. Let’s compile a simple program that runs a\r\nping command via bash and name it ping-google-dns:\r\nhttps://www.intezer.com/blog/malware-analysis/elf-malware-analysis-101-part-3-advanced-analysis/\r\nPage 6 of 21\n\nFigure 3: ping-google-dns source code\r\nLet’s run the program and on another terminal run pstree | grep ping-google-dns:\r\nFigure 4: Process tree created by ping-google-dns\r\nWe ran the ping-google-dns program from a terminal (bash process) which called sh binary (a command\r\nlanguage interpreter) that called the ping binary.\r\n2. Forks: fork() creates a new, duplicate process of the called process. The new process is called a child\r\nprocess and it will have a different process ID than its parent. Let’s re-compile the ping-google-dns source\r\ncode, this time with the addition of a fork() call.\r\nFigure 5: ping-google-dns source code\r\nLet’s run the program and on another terminal run pstree | grep ping-google-dns.\r\nFigure 6 shows what the process tree looks like with one fork call. You will see in the screenshot below\r\nthat the same program has two process IDs.\r\nhttps://www.intezer.com/blog/malware-analysis/elf-malware-analysis-101-part-3-advanced-analysis/\r\nPage 7 of 21\n\nFigure 6: Process tree created by ping-google-dns\r\n3. Threads: Threads provide multiple executions within the program. A process thread will not create a new\r\nprocess ID. Let’s compile this code that runs three threads as print-something (the compiled file can be\r\ndownloaded from here).\r\nFigure 7: print-something source code\r\nNow let’s run the program and run pstree | grep print-something on another terminal. Figure 8 emphasizes what\r\nthe process tree of a program that runs with three threads will look like.\r\nhttps://www.intezer.com/blog/malware-analysis/elf-malware-analysis-101-part-3-advanced-analysis/\r\nPage 8 of 21\n\nFigure 8: Process tree created by print-something\r\nProcess Monitoring Tools\r\nSysinternals Suite provides convenient GUIs for monitoring all processes that are running on a Windows machine\r\n(among other things). Microsoft’s ProcMon-for-Linux based on ProcMon and Intezer’s Linux Expl0rer inspired\r\nby ProcExp, are intuitive solutions for Linux process tracking.\r\nSystem Calls\r\nOnly the kernel can perform changes outside of the process’s own memory space. The process must ask the kernel\r\nto perform tasks such as creating files or writing output. This is where system calls come into play.\r\nSyscalls (system calls) are the interface used by the application to request services from the kernel. Syscalls are\r\nusually invoked via glibc wrappers and not directly to the kernel because of portability. The low level syscalls\r\ndiffer between architectures which is why glibc handles these differences instead of the developer.\r\nSyscalls are an interface that the malware must pass through in order to cause actual harm to the system.\r\nAnalyzing syscalls can help us understand how the file interacts with the system and how it operates behind\r\nthe scenes.\r\nstrace is a powerful tool to trace a file’s system calls. Run strace whoami on your Linux VM and take a look at\r\nthe output. Each row in the strace output is a syscall, and the first syscall will be execve which stands for execute\r\nprogram. Each system call has a return value that varies between calls. It can be a file descriptor (integer) or 0 on\r\nsuccess, -1 on error and more.\r\nThese are some interesting syscalls we will look for by analyzing the strace output:\r\nopen/openat – open and possibly create a file.\r\nread – read from a file descriptor.\r\naccess – check user’s permissions for a file.\r\nwrite – write to a file descriptor.\r\nmkdir/mkdirat – make directories.\r\nconnect – initiate a connection on a socket.\r\nsocket – create an endpoint for communication.\r\nexecve – execute program.\r\nhttps://www.intezer.com/blog/malware-analysis/elf-malware-analysis-101-part-3-advanced-analysis/\r\nPage 9 of 21\n\nLet’s try it ourselves. Run the trace-me file on your VM using strace. Use the -o flag to save the command output:\r\nstrace -o out.txt ./trace-me:\r\nFigure 9: trace-me output\r\nNow, let’s read the strace output to see what happened on the system. Run cat out.txt:\r\nFigure 10: strace output\r\nYou will see the file creates the .tomato directory under tmp directory, and creates a file\r\nanswer.txt inside this directory. If you look carefully on the flow, you can see the return value of openat for the\r\nanser.txt file is 3, which is the file descriptor. Then, write syscall, “I was created!!” uses the file descriptor 3 as\r\nan input. This means that this text is written to the answer.txt.\r\nTips:\r\n1. In most cases the syscalls output will be much bigger than the last example. It is recommended to always\r\nsave the strace output to a text (strace -o out.txt ./file). Make sure that you have a convenient text editor\r\nsuch as Sublime Text that will help you analyze the large text file.\r\n2. To gain full visibility on all syscalls of the processes created by the file, including forks, you can run strace\r\nwith the fork flag -f (strace -f ./file).\r\n3. The default strings length is 32. Use the -v (verbose) and -s (string size) flags to see more characters\r\n(strace -v -s 150 ./file).\r\n4. To reduce noise, you can choose which syscalls will be presented on strace output using the -e flag. For\r\nexample, if you are searching for network-related calls together with read and write calls, you can run\r\nstrace -e network,read,write ./file.\r\nLearn more about syscalls\r\nhttps://www.intezer.com/blog/malware-analysis/elf-malware-analysis-101-part-3-advanced-analysis/\r\nPage 10 of 21\n\nPersistence\r\nOnce a malware finds its way into a compromised system, it will often attempt to achieve persistence in order to\r\nsurvive reboot. Another reason why malware developers add persistence capabilities is to harden removal efforts,\r\nwhich is also attempted by other malware families in order to gain a foothold on already compromised systems.\r\nThis is more common among CoinMiners, which will search for other known Miners on a compromised machine\r\nand attempt to kill them, to be the only CoinMiner running on the system and ultimately win the machine’s\r\nresources. See War of Linux Cryptocurrency Miners: A Battle for Resources.\r\nDetecting persistence methods is important for understanding how to respond to malware on a\r\ncompromised machine. Killing the process is not always enough to mitigate the threat, the persistence\r\nmethods should be cleared as well.\r\nThese are the most common persistence methods used by Linux malware:\r\n1. Cron – Malware will create scheduled tasks to run periodically on a system using cron jobs. crontab and\r\nanacrontab are the configuration files used for cron and anacron services which are in charge of executing\r\nscheduled tasks. The malware will write registries to the configuration files which are located under:\r\n/etc/crontab, /var/spool/cron/, /etc/cron.d/, /etc/anacrontab, /var/spool/anacron/. The following XMRig\r\nMiner dropper uses crontab as one of its persistence methods. Figure 11 emphasizes what a crontab registry\r\nlooks like:\r\nFigure 11: crontab registry written by a malware\r\nNote: Running crontab -l will list the existing cron jobs per user. Using root privileges, you can either run crontab\r\n-l -u \u003cuser\u003e or cat /var/spool/cron/crontabs/\u003cuser\u003e for specific users. To view the cron jobs for all users, run cd\r\n/var/spool/cron/crontabs/ \u0026\u0026 grep . *\r\n2. Services – Linux has initialization scripts that are used to start services on system boot. The program in\r\ncharge of starting the rest of the system will run as PID 1 (you can explore your /proc/1 directory).\r\nMalware will often attempt to gain persistence by creating a service which will run by the init program on\r\nboot. The init program varies between Linux distributions and versions, however, systemd is most common\r\nthese days. rc.d and init.d are older init services which are still used in certain Linux distributions. Learn\r\nmore about why init.d was replaced by systemd\r\nThe service will commonly be found under the following paths: /etc/systemd/system/, ~/.config/systemd,\r\n/etc/rc.d/, /etc/init.d/.\r\nhttps://www.intezer.com/blog/malware-analysis/elf-malware-analysis-101-part-3-advanced-analysis/\r\nPage 11 of 21\n\nIPStorm Linux version is an example of a malware that gained persistence by creating a service under\r\n/etc/systemd/system/storm.service. Figure 12 emphasizes the structure of a systemd service file.\r\nFigure 12: storm.service content\r\n3. Event Triggered Executions – Once a user logs in or a new shell session is created, Linux will\r\nautomatically launch executables by using configuration files. These configuration files are bash scripts\r\nwhich can be edited to trigger a malware. Files locations: /etc/profile.d, /etc/profile, /etc/bash.bashrc,\r\n∼/.bashrc, ∼/.bash_profile, ~/.bash_login, ~/.profile. Linux Rabbit is a malware that uses the .bashrc to set\r\nup persistence.\r\n4. Graphical Desktop Autostarts – Similar to event triggered executions, once a user logs in via a graphical\r\ndesktop environment such as GNOME or KDE, Linux will automatically search for desktop entries to\r\nexecute applications on startup. A generic location for desktop entries is under ∼/.config/autostart/. Other\r\npossible locations include: ~/.kde/Autostart,~/.kde/share/autostart, ~/.kde4/Autostart, /usr/share/autostart/,\r\n/etc/xdg/autostart/. The autostart service will have a .desktop suffix. This persistence method is relevant for\r\nmalware that targets endpoints. ElectroRAT’s Linux version gains persistence by creating a desktop entry\r\nunder ~/.config/autostart/mdworker.desktop.\r\n5. Loadable Kernel Modules (LKM) – The Linux kernel is designed to allow loading of external pieces of\r\ncode called kernel modules. Kernel modules are automatically loaded on system boot. Because the Linux\r\nkernel runs as root, and the modules can be loaded dynamically (using modprobe or insmod) with no need\r\nto reboot the system, this method is commonly used for rootkits as well. Malware that attempts to gain\r\npersistence via this method will create malicious kernel modules that will be loaded to the kernel and run\r\nhttps://www.intezer.com/blog/malware-analysis/elf-malware-analysis-101-part-3-advanced-analysis/\r\nPage 12 of 21\n\non boot. The location of the kernel modules is under: /lib/modules/$(uname -r). By running lsmod you can\r\nsee what kernel modules are currently loaded.\r\n6. Hijack Execution Flow – Dynamically linked binaries use shared libraries during runtime (in the previous\r\narticle we explained the differences between dynamically and statically linked files). These libraries are\r\nloaded by the dynamic linker which searches for libraries on absolute paths and common directories.\r\nLD_PRELOAD is an optional environmental variable containing paths to shared libraries or objects. The\r\ndynamic linker will load the libraries in LD_PRELOAD before loading any other shared library (including\r\nlibc). Malware developers can set LD_PRELOAD to point to malicious libraries. Once a dynamically\r\nlinked binary is executed on a compromised machine, it will load the malicious library too. HiddenWasp is\r\na malware that uses LD_PRELOAD for persistence.\r\nTo summarize this section, there are different startup locations which can be used as persistence methods for\r\nmalware. However, the most commonly used methods are services and cron jobs.\r\nTip: A convenient way to check if a malware attempts to gain persistence is by analyzing the syscalls (strace\r\noutput) and searching for known methods. For example, you can run cat strace_output.txt | grep cron to search\r\nfor any interaction with the cron process.\r\nNetwork Sniffing\r\nSo far we covered how to monitor a file’s activity internally on the system. You can understand if a malware\r\ninteracts with a C\u0026C or external services by analyzing network-related syscalls such as socket and connect.\r\nHowever, syscalls are not the way to go for network monitoring. You should use a packet sniffing and network\r\nmonitoring tool to analyze the traffic. The most popular tools for this purpose are tcpdump and Wireshark, both\r\nbased on libpcap. tcpdump is a CLI tool that should be preinstalled on commonly used Linux distributions.\r\nWireshark has similar functionalities to tcpdump and provides a convenient GUI.\r\nTo install Wireshark on your VM run the following commands:\r\nsudo add-apt-repository ppa:wireshark-dev/stable\r\nsudo apt install -y wireshark\r\nsudo wireshark\r\nTip: Make sure to run Wireshark before running the file you are analyzing so that you won’t miss any packets\r\nrelated to the malware.\r\nSandboxes\r\nSandboxes can accelerate analysis by providing context about the file’s behavior on a machine without the hassle\r\nof opening a VM, running the malware and relevant tools. They will not always replace a hands-on, deep dive\r\nanalysis of a VM, but sandboxes help you pinpoint interesting behaviors while saving you time.\r\nHere are some relevant tools:\r\n1. Hybrid-Analysis – Online\r\nhttps://www.intezer.com/blog/malware-analysis/elf-malware-analysis-101-part-3-advanced-analysis/\r\nPage 13 of 21\n\n2. Hatching-Triage – Online\r\n3. LiSa – Open-source\r\nReal Life Example\r\nLet’s practice your dynamic analysis skills! We will begin with initial analysis to gather insights and then proceed\r\nto dynamic analysis. Our mission is 1. Understand how the file behaves and 2. See how dynamic analysis tools\r\ncome in handy.\r\nOur test sample? This ELF malware found in the wild.\r\nA quick side note. Uploading this file to Intezer Analyze classifies it as Reekoobe, based on code reused from\r\nprevious Rekoobe samples. We will analyze the file manually for practice anyway.\r\nStep one, download/copy the sample to your VM. Make sure:\r\n1. Your environment is prepared based on the Analysis Environment Preparation section.\r\n2. You have a clean snapshot of your VM with the relevant tools. In this example we will be using Wireshark\r\nand Sublime Text editor. Other tools should be preinstalled on the machine.\r\nLet’s begin with static analysis and try to read the file’s symbols to see if there are any human readable function\r\nnames. Run readelf -s sample. There is no output for the command, which means the file has been stripped.\r\nLet’s read the file’s program headers by running readelf -l sample. The following image shows the command’s\r\noutput:\r\nhttps://www.intezer.com/blog/malware-analysis/elf-malware-analysis-101-part-3-advanced-analysis/\r\nPage 14 of 21\n\nFigure 13: Sample’s program headers\r\nWe can tell the file is statically linked because there is no dynamic symbols table or dynamic program header.\r\nLet’s run the strings command on the file. Because the file is statically linked you should expect to see a large\r\nnumber of strings related to libc. Figure 14 is a snippet of the strings commands output:\r\nhttps://www.intezer.com/blog/malware-analysis/elf-malware-analysis-101-part-3-advanced-analysis/\r\nPage 15 of 21\n\nFigure 14: Snippet from strings output\r\nThe strings snippet is a big indicator that the file will attempt to create a service to gain persistence. “systemctl\r\nenable likemae” and other strings can help us understand that the service name will be likemae. Another\r\ninteresting string is c[.]linux-hosts[.]com which could be the C\u0026C.\r\nNow that we have gathered enough information in the initial analysis step, let’s proceed to dynamic\r\nanalysis.\r\nFirst, prepare a running program of Wireshark and then run the sample with strace: sudo strace -f -o out.txt\r\n./sample. We will analyze this malware as if it ran with a privileged user to see its full capabilities.\r\nhttps://www.intezer.com/blog/malware-analysis/elf-malware-analysis-101-part-3-advanced-analysis/\r\nPage 16 of 21\n\nOpen the out.txt with a convenient text editor such as Sublime Text. The following snippet shows the beginning of\r\nthe strace output:\r\nFigure 15: Snippet from strace output\r\nAnalyzing syscalls from the snippet, it’s clear that this malware checks for the existence of likemae.service with\r\nthe access syscall. The return value is -1 because the service doesn’t yet exist on the machine. The malware\r\nrenames the file and locates it under /usr/bin/likemae using the rename syscall. Next, using the open syscall, the\r\nmalware creates likemae.service and writes to it.\r\nLet’s view the service’s full content:\r\nFigure 16: likemae.service content\r\nYou can also use grep to find interesting syscalls. Run cat out.txt | grep exe to see all executions created by the\r\nmalware.\r\nhttps://www.intezer.com/blog/malware-analysis/elf-malware-analysis-101-part-3-advanced-analysis/\r\nPage 17 of 21\n\nThe malware made sure that the likemae service would run. Check that the service is indeed active on your\r\nmachine by running systemctl | grep likemae.\r\nFigure 17: likemae service is active\r\nSo far, you know the malware created persistence on the machine using the service creation method and copied\r\nitself to the /user/bin/likmae. You can also tell the process that we ran has exited after establishing persistence.\r\nLet’s check if a process called likemae is currently running on our system. Run pstree -p | grep likemae (-p flag\r\nto retrieve the process ID).\r\nFigure 18: likemae process is running with PID 15083\r\nIf we run cat /proc/1503/cmdline, we will see that is /bin/bash. This is because the process was triggered by the\r\nservice.\r\nNow that the service exists and the malware established persistence, you can expect the new malware process to\r\nperform different actions on the system. Attach strace to the likemaes’s PID by running strace -p 15083.\r\nAnalyzing syscalls we can understand that the process attempts to connect to the c[.]linux-hosts[.]com host and\r\nthen sleeps for 30 seconds (see nanosleep syscall). The following snippet shows the connection attempt loop. You\r\ncan see the syscalls that are made in order to connect to the C\u0026C.\r\nhttps://www.intezer.com/blog/malware-analysis/elf-malware-analysis-101-part-3-advanced-analysis/\r\nPage 18 of 21\n\nFigure 19: Connection attempt loop\r\nYou can view the network connection attempts in Wireshark as well.\r\nFigure 20: Network connection attempts in Wireshark\r\nIn Figure 20, you can see the host DNS resolution and the attempt to reach it via TCP. The TCP connection is not\r\nestablished, meaning the host doesn’t reply with a [SYN,ACK] packet but rather a [RST,ACK] response is sent\r\nback. The port the malware attempts to connect to on the C\u0026C is closed.\r\nhttps://www.intezer.com/blog/malware-analysis/elf-malware-analysis-101-part-3-advanced-analysis/\r\nPage 19 of 21\n\nBecause the C\u0026C is not reachable as expected, we have essentially come to a “dead end” with the dynamic\r\nanalysis step. You can still explore the domain for other open ports but we will not dive into it further in this\r\narticle. Nonetheless, you gained crucial insights on how the malware operates once it runs, how to detect it on\r\ncompromised systems, and how to clear the malware from your system.\r\nTip: Some malware behave differently when they run as a privileged vs. an unprivileged user. The malware we\r\nhave analyzed will not gain persistence if it runs as an unprivileged user. It is recommended to run the file as both\r\nprivileged and unprivileged users to understand the full spectrum of its capabilities.\r\nWrap-Up\r\nWe reviewed ELF dynamic analysis and detailed the different components and tools relevant for this step. You\r\nlearned how to gather insights about a file’s behavior using these tools. You also learned how insights gathered\r\nduring initial analysis can help you focus on certain components during dynamic analysis.\r\nThere are certain cases where you will hit a dead end during the dynamic analysis process. The C\u0026C could be\r\ndown, the malware runs on a particular environment or time zone, and more. Remember, the goal in dynamic\r\nanalysis is to gather additional insights on how the malware behaves. This will help you detect the malware on\r\ncompromised systems, collect indicators related to the malware such as file names, C\u0026C, persistent methods and\r\nmore. This can lead you to connect the malware to other tools, campaigns and/or threat actors.\r\nDynamic analysis should be done responsibly. The safety of your system and network together with other\r\nmachines should be taken into consideration when analyzing malware dynamically.\r\nWhat’s Next?\r\nNext up you will learn how to get payloads from packers and loaders by extracting memory dumps.\r\nAppendix\r\nThese tools and commands were used or mentioned in this article:\r\n1. Hatching-Triage\r\n2. Hybrid-Analysis\r\n3. Intezer Analyze\r\n4. Linux Expl0rer\r\n5. Linux VM\r\n6. LiSa\r\n7. OpenSSH\r\n8. pidof\r\n9. ProcMon-for-Linux\r\n10. ps\r\n11. pstree\r\n12. readelf\r\n13. strace\r\nhttps://www.intezer.com/blog/malware-analysis/elf-malware-analysis-101-part-3-advanced-analysis/\r\nPage 20 of 21\n\n14. strings\r\n15. Sublime Text\r\n16. tcpdump\r\n17. top\r\n18. Wireshark\r\nSource: https://www.intezer.com/blog/malware-analysis/elf-malware-analysis-101-part-3-advanced-analysis/\r\nhttps://www.intezer.com/blog/malware-analysis/elf-malware-analysis-101-part-3-advanced-analysis/\r\nPage 21 of 21",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia"
	],
	"references": [
		"https://www.intezer.com/blog/malware-analysis/elf-malware-analysis-101-part-3-advanced-analysis/"
	],
	"report_names": [
		"elf-malware-analysis-101-part-3-advanced-analysis"
	],
	"threat_actors": [
		{
			"id": "eb3f4e4d-2573-494d-9739-1be5141cf7b2",
			"created_at": "2022-10-25T16:07:24.471018Z",
			"updated_at": "2026-04-10T02:00:05.002374Z",
			"deleted_at": null,
			"main_name": "Cron",
			"aliases": [],
			"source_name": "ETDA:Cron",
			"tools": [
				"Catelites",
				"Catelites Bot",
				"CronBot",
				"TinyZBot"
			],
			"source_id": "ETDA",
			"reports": null
		}
	],
	"ts_created_at": 1775434948,
	"ts_updated_at": 1775791458,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/6d8967f37faf786759b2114fa15ff10bcd95e908.pdf",
		"text": "https://archive.orkl.eu/6d8967f37faf786759b2114fa15ff10bcd95e908.txt",
		"img": "https://archive.orkl.eu/6d8967f37faf786759b2114fa15ff10bcd95e908.jpg"
	}
}