Posted on by

Malware analysis with PEframe

Hello, aspiring ethical hackers. In our previous blogpost, you learnt about malware analysis and difference between static analysis and dynamic analysis of malware. In this article, you will learn about peframe, a malware analysis tool.

PEframe is an open source tool to perform static analysis on portable executable malware and malicious MS Office documents. Let’s see how to perform analysis of portable executable files using this tool. For this, we will be using Kali Linux.

In static analysis, the malware sample is analyzed without executing it whereas in dynamic analysis the sample is executed in a controlled environment. Static analysis is performed on the source code of the sample portable executable. PEframe reveals information about suspicious files like packers, xor, digital signature, mutex, anti debug, anti virtual machine, suspicious sections and functions and much more. PEframe can be installed in Kali Linux as shown below.

Open a terminal and type the command as shown below to clone PEFrame from Github.

After PEFrame is cloned successfully, a new directory is formed with name peframe. You are automatically taken into this directory. This tool requires simplejson (a subset of JavaScript). So install it using pip command. Next, we need to run the setup.py file from the directory. Since it is a python file, we need to run the command “python3 setup.py” install to install PEframe.

Once the installation is finished, type command “peframe -h” to see its simple usage

Before we analyze the portable executables, let us analyze some files we created for tutorials of our magazine. The first one is msf.pdf we created using Metasploit.

As you can see in the above image, we found not only an IP address but also an url hosting some executable file. It can be assumed that as we open this pdf file, another executable will be downloaded from the IP address and executed in our system. Let us now analyze a hta file created with Metasploit next. This file is analyzed as a HTML document with IP address and it has a library called kernel32.dll. This file probably opens a payload when clicked upon. Given below is another similar file in visual basic format.

Given below is a macro file. You can see all these files have an IP address where probably a listener is running.

Now let us analyze a portable executable file. Kali Linux has some exe files already stored in its windows-binaries folder. We will analyze the plink.exe file.

Plink.exe is a command line utility file similar to UNIX ssh. It is mostly used for automated operations. As you can see in the image given above, the program is giving more detailed information to us than the other files. The plink.exe has four sections and none of them appears to be suspicious. But the file has a packer, mutex and antidbg. The packer it used is Microsoft Visual C++ which is normally used for genuine programs.

Given above is its Antidbg and Mutex information. The dynamic link libraries it imports is also given. Given below are the apis (application programming interfaces) used by the file.

The filenames found in the portable executable are given in the image below. As you can see it has a big list of filenames.

Metadata is data about the data. Metadata reveals a lot of information about a file. Given below is the metadata of our portable executable. We can see that it is a part of Putty Suite.

Even the description of the file is given. Normally malware does not contain so much information about itself like this Plink file. Only genuine files contain so much information because they have no use to hide themselves. Now let us analyze another file. This file is also present in Kali Linux and it is a keylogger. It is klogger.exe present in the same windows-binaries folder.

As you can see in the above image, the file which has five sections has two suspicious sections and the packer it uses is ASPack v2.11. Let us have a look at its suspicious sections once.

Given below in the image are its api alerts and filenames. As you have observed, this file reveals very less information than the previous analyzed file. This in itself does not mean that the file is malicious but it gives a general idea about it. That’s all about Forensics using static analyzer PEFrame. We will be back with a new tool in our next howto.

Next, learn about Ollydbg, a debugger.

Posted on by

Linux post exploitation with Metasploit

Hello aspiring hackers. In our previous blogpost, you learnt about POST exploitation in detail. In this article, you will learn about Linux post exploitation. Post exploitation activities performed on a linux system is known as Linux post exploitation. Obviously this stage will come after successfully gaining access to the Linux system. It’s a good time to learn about Linux hacking.

In this article, we will learn how to perform linux postex with metasploit. Metasploit has many POST modules that can be used to enumerate the Linux system. After getting a successful meterpreter session on the target Linux system, we background the current session.

You can search for all the Linux post-ex modules using command shown below.

use post/linux/ <tab> </tab>

This will reveal all the post-exploitation modules of Metasploit. The first module we will see is Linux configuration enumeration. The enum_configs module is used to collect information from the configuration files of applications commonly installed in the system. These applications may include Apache, Nginx, Snort, MySQL, Samba, Sendmail, sysctl, cups, lampp and SNMP etc. This POST module searches for a config file in the application’s default path and if the application exists on the target system, the module will download the files and store it.

If the application doesn’t exist or the config file is moved from its default location, this module will display the “file not found” message. After loading the module, set the session id and run the exploit. Here is the enum configs module in action as shown below.

Learn how to perform Windows post exploitation with Metasploit.

Posted on by — 1 Comment

Testing CVE 2018 17456 with Metasploit

Hello aspiring ethical hackers. In our previous blogpost, you learnt how to use Metasploit framework. In this article, you will learn what is CVE-2018-17456 vulnerability and how to test this vulnerability with Metasploit.

What is CVE-2018-17456 vulnerability?

CVE-2018-17456 is a vulnerability affecting submodules of Git. A Git submodule is a repository that is included within another Git repository. The vulnerability arises when a submodule URL which starts with a dash e.g “-u./payload” is passed as an argument to git clone, the file “payload” inside the repository is executed. This vulnerability affects Git versions 2.14.5, 2.15.3, 2.16.5, 2.17.2, 2.18.1, and 2.19.1 and lower.

This Metasploit module creates a fake git repository which contains a submodule containing the payload. The vulnerability is triggered when the submodules are initialized or cloned. (e.g git clone –recurse-submodules URL)

This module is a local exploit module and works on Git versions 2.7.5 and lower. Now let us see how this module works. Start Metasploit and load the exploit module as shown below. Type command “show options” to see all the options we need for this module to run.

Set the options LHOST, git_uri and LPORT options as shown below. The git_uri option sets the URL malicious git submodule. Use command “run” to start our Git HTTP server.

All we need to do now is send the URL of the Git repository we created to target users. This requires social engineering. As the user clones this URL, we will get a command session on the target. Here we are testing this on KaIi Linux 2016 machine which has the vulnerable version of Git installed. Let’s see what happens on the target machine.

As this happens on our target system, we will get a command shell on our attacker system as shown below.

We can see the active sessions using the command “sessions”.

That is how you can test for CVE 2018 17456 vulnerability. Learn about PrintNightmare vulnerability.

Posted on by — 1 Comment

Vulnerability assessment (VA) for beginners

Hello, aspiring ethical hackers. In our previous blogpost, you learnt about vulnerability scanning. In this article you will learn about vulnerability assessment.

What is vulnerability assessment?

Vulnerability assessment (VA) is sometimes interchangeably used with vulnerability scanning but is entirely different form vulnerability scanning. VA is a systematical review of vulnerabilities or weaknesses in a system or a network or even in an entire company. While vulnerability scanning is just scanning for vulnerabilities, Vulnerability assessment also assigns security levels to the vulnerabilities identified and suggests remediation or mitigation if needed.

Types of vulnerability assessments

As vulnerability assessment has a larger scope, there are different types of vulnerability assessments. They are,

1. Host assessment:

When a single host or a system (which can include server or client) is assessed for vulnerabilities, it is called host assessment.

2. Network assessment:

When vulnerabilities in an entire network are assessed, it is known as network VA. This can include all the devices, gateways and servers in the entire network.

3. Database assessment:

When vulnerabilities of a database are assessed, it is known as a database assessment.

Stages of a vulnerability assessment

VA primarily consists of four stages. They are,

1. Vulnerability identification:

The first stage of the VA is to identify the vulnerabilities in a host network or any other resources. This involves scanning for vulnerabilities using automated tools.

2. Vulnerability analysis:

The second stage is to analyze the vulnerability identified. This includes identifying the source of and cause of the vulnerabilities.

3. Risk assessment:

The third stage in VA includes assessing the risk of the vulnerability. In this stage, a rank or security level is given to each vulnerability detected. This rank depends on the severity of the vulnerability, how simple it is to exploit this vulnerability, ease of access, and what a hacker can get if he is successful in exploiting it.

4. Remediation:

The final step of VA is to fix or remediate the vulnerability. This stage can include developers, operation teams and cybersecurity professionals.

Some of the tools that can be used to perform vulnerability assessment are Nessus, OpenVAS, Burp suite, Nikto, Wireshark etc.

Posted on by

Meterpreter archmigrate module

Hello aspiring ethical hackers. In our previous blogpost, you learnt all about the meterpreter payload. In this blogpost, you will learn about the archmigrate module of Metasploit. This module checks if the meterpreter architecture is the same as the Operating System architecture (OS) and if it’s incompatible it spawns a new process with the correct architecture and migrates into that process. It is a POST module.

What is architecture? As we all know there are two main system architectures 32bit and 64bit. Sometimes, we happen to select a 32bit meterpreter payload for a 64bit target system.

Sometimes there may be compatibility issues if we get a 32bit meterpreter session on a 64bit machine and vice versa. This is the exact scenario in which this module is helpful. To overcome the problems of incompatibility, we need to get a new 64bit meterpreter session or just use the archmigrate module to create a new process with the same architecture as the target OS and migrate to that process. Let’s see how this module works.

To use this module, we need to background the current meterpreter session using command “background”. Then load the archmigrate exploit as shown below. Type command “show options” to have a look at the options it requires.

meterpreter architecture migration from 32bit to 64bit and vice versa

We need to only set the session id of the meterpreter session we just sent to background and the exploit is good to go.

If you see in the above image, our exploit failed to run for the first time. This is because in the previous session we had system privileges and if we run this module we may lose the system privileges. But don’t worry, we can change the options to overcome this problem.

Set “ignore_system” option to true and you should be fine to go. This time the exploit ran successfully. As you can see in the above image, our target is a 64bit machine and our meterpreter migrated to a 64bit process successfully. Lets check by typing command “sessions -l” to see the available sessions. You can see we have a 64bit meterpreter session now. Job performed.