Penetration testing

Threat Hunting – Command and Control Center - OFFICE WORK

This is a lab that is conducted in a test bed. The resources were downloaded from malware.trafficanalysis.net. The samples provided came from a case study of an Office workstation that was a victim of malware.

Scenario

Many malware developers strengthen and employ different strategies for evading the defense mechanism, but the basics remain the same. We will consider a modern-day scenario in a typical office where suspicious activity is identified in a command and control center communication. An office workstation is infected, and we are called in to help them in determining the user account affected, what kind of malware attack it is, and if the infection indicates any lateral movement. Also, we will analyze the traffic deeply to probe the command and control center. We can dig deeper without limiting ourselves to the analysis of the current research. The research will be based purely on freely available tools for analyzing.

Earn two pentesting certifications at once!

Enroll in one boot camp to earn both your Certified Ethical Hacker (CEH) and CompTIA PenTest+ certifications — backed with an Exam Pass Guarantee.

View Pricing

The files which have been provided are as follows:

• 2018-02-13-traffic-analysis-exercise.pcap.zip
  • The primary .pcap file.

Tools we will be using:

• Wireshark

Download URL: http://www.malware-traffic-analysis.net/2018/02/13/2018-02-13-traffic-analysis-exercise.pcap.zip

As suggested in an earlier article: https://resources.infosecinstitute.com/threat-hunting-malspam-japan-office-infected/#gref we are following the same approach here as well. We will start by manually analyzing some of the packets and then proceed with automated detections. In an operational environment, you can also pull out the network firewall, IDS and IPS logs. This is done to avoid any unnecessary delays in the reporting since in-depth analysis can consume more time in hunting down malware rather than focusing on necessary information. We start by exploring the. pcap in Wireshark. The main aim here would be to obtain starting pointers with regards to the affected system as listed below:

• Domain Name.
• Hostname.
• IP Details.
• Operating system version.
• Packets Statistics.

Note: Ensure that all the protocols are enabled for the captured file by going to "Analyze à Enable Protocols" as shown in the below image.

If the file is not tampered with, we begin the process. The first two are requests for the DNS handshake process queries to enter a domain-controlled environment. The connected machine transmits queries containing certain core components such as SRV, A and C-Name records that are used by AD and Domain computers. Other than SRV they are also Non-SRV-Aware components. They can be detected based on the difference in the Mnemonics, type and DNS record fetch query.

The highlighted "DC Record - _ldap._tcp.dc._msdcs.<DnsDomainName>" record is used to locate the domain controller on any network environment. So, the next packet will contain the domain details. We can get the domain name "MOONDUSTRIES-DC.moondustries.com" and IP address"10.23.1.7". This proves we are on track with the investigation.

Once the Domain controller has been identified, the user will move on to the authentication phase. For the user to obtain a ticket, the user must share a TGT mainly known as a ticket-granting ticket to the KDC (Kerberos Key Distribution Center) which is available on the domain controller. A user always gets a TGT from the Kerberos domain service once their password is validated and the session is logged.

We are not going into the deep of Kerberos authentication since we just need the flow depicted as follows in more straightforward terms and pretty much self-explanatory.

Pic credit: http://searchwindowsserver.techtarget.com/tip/Kerberos-protocol-What-every-admin-should-know-about-Windows-authentication

The exciting thing we get here is the hostname of the victim machine shown as "reginald-pc." These are pretty much the basics, but it can prove helpful when tracking down further processes.

Another few more Kerberos authentication packets which are standard and mandatory to initiate the authentication process.

Some SMB request and responses are identified, which again provide a ton of information. There was an attempt made to connect to the default $IPC shares. A couple of MTLMSSP request and responses which primarily assist in the NTLM challenge-response processes. We can confirm here the details observed earlier and the operating system which is Windows. We have yet to identify the exact operating system in use.

Progressing ahead we observe some Web Proxy Auto-Discovery Protocol (also known as wpad) requests were made. This protocol downloads the configuration files which help determine the proxies in use for a destination URL. The web server here is not configured for those configuration files and hence returned no such name responses.

With over 290 packets analyzed and we see only one HTTP communication which undoubtedly legitimately belongs to the Microsoft domain. This packet reveals a significant amount of information belonging to the victim machine. However, we still didn't get any clue on the operating system. Also, no external network interactions as well, which proves the system communicated inside domain as of now.

Request from 519 to 619 seems interesting since we have a hit on an external IP address. The first few requests have IGMP messages belonging to the type of general query and leave group query for the multicast addresses. IGMP is mainly used for setting up multicast group membership.

We have a hit here with an external IP address interaction. The IP address is "52.219.24.113". A quick look at the whois records and the blacklisting check of the IP revealed no interesting information. This IP address still cannot be ignored but can be flagged since we see a large amount of data transferred to and from IP with a specific port and specific length. Generally, the CnC tends to change the IP once it has been blacklisted or present on the environment for a very long time.

Another external interaction observed on IP "185.86.151.37". A blacklist check provided a clue to move ahead with this IP.

The reason we targeted this IP was there is a large number of packets transferred from port "49213" to port "2200" at regular intervals as well the length is "1409" in size. This may indicate a command and control center establishment and exfiltration process anomaly behavior. With advanced IDS and IPS, this one can easily be tracked and flagged down. Some advance APT detectors and Threat hunting frameworks detect this as exfiltration activity and warn the network operations center to trigger specific actions.

The packet, when followed with TCP stream, is observed having magic bytes of a JFIF file (JPEG File Interchange Format), and the obfuscation is present along with the encrypted channel communication between the attacker and the victim. We can use automated approach here for the sake of co-relation which saves time and improves efficiency since we will be only targeting the obtained destination now.

Before proceeding, we can now draft the first stage of hypothesis here predicting the earlier stated things as below:

• Domain Name: - MOONDUSTRIES-DC.moondustries.com
• Hostname: - REGINALD-PC
• IP Details: - Workstation IP:10.23.1.205 Domain controller IP: - 10.23.1.7
• Operating system: – Windows (Operating System Unknown)

Further moving with the investigation in packet analysis and automated co-relation approach we use Wireshark inbuilt packet statistics. They prove worth when analyzing an enormous amount of corporate traffics.

It even helped in exporting the data into .csv or .json. The export objects help in extracting the relevant objects available from the data streams however no data stream objects were identified from this pcap.

To get in-depth with automated alerts, we use "packettotal.com" tool available online. Do note that when you upload the sample, the sample will be available publicly hence it is advisable to use it responsibly.

Our mere suspicion was proved right we have a Trojan backdoor detection on the victim IP "185.86.151.37". We also observe the external IP one to be the identified one. The result can be extracted or printed directly.

Some of the behavior we see is the target, and source port never changes. The transmission starts from time "2018-02-13 05:07:43". File transfer shows no sign however the triggered alert signature shows screenshot upload event from the start of time. The screenshot upload event took place at regular intervals and send back to the malicious IP. We can co-relate the earlier JFIF images that are sent on to the malicious server.

The IP2Geo tracker helped identify the location which is in UK, London. A quick whois result indicated the Makonix SIA as the organization responsible for the IP Address ownership. Makonix ISP is a cloud hosting provider. This indicated that the attacker used this IP address to host his malicious content and then maybe kept the malicious downloaded content on the Makonix cloud server.

Coming back to the identified Trojan "ET TROJAN Backdoor.Win32.DarkComet " we need a deeper understanding of the process of how this malware executes and sets the command and control center. This would be the last step in our investigation.

Having used Google to the rescue again, we identify below information:

• The malware is commonly identified as Network Trojan affecting the cracks or serial key finder's tools which help hack the installed software to extend the license or using it without the requirement of a product key.
• Also, the traffic observed is commonly from a specific port to a malicious IP address.

  Some of the Indicators of Presence:

  • Contacts specific server/domains.
  • Creates Mutexs.
  • Cryptographic GUID creation
  • Configuration file access Logs
  • Executable installation's eg: ("HmyNIlfha.exe" has type "PE32 executable (GUI) Intel 80386 Mono/.Net assembly for MS Windows")
  • RDP service key read events.
  • Modified Proxy setting.
  • Hook and patched for the running processes
  • Exposure of registry keys for the installed applications.
  • Launching anonymous process with predefined malicious environment variables.
  • Various API calls to Windows kernel drivers.

Conclusion:

We have reached a level where we have confirmed various attack agents and can now brief up the process with all the available details. This can further be used for employing the defensive mechanism by the affected organization. This also will be considered as final threat hunt report.

Infected Machine Details:

Hostname: REGINALD-PC

IP Address: 10.23.1.205

Infection Time and Date: Feb 13, 2018, Command and Control Center Operation

Operating System: Windows

Malicious IP Observed:

• 185.86.151.37

IP Registered Countries:

United Kingdom (London)

Malware Variants Observed:

ET TROJAN Backdoor.Win32.DarkComet

Malware Impact:

Perform data exfiltration by dropping executable obtained mainly from cracked software. Enables anonymous programs. Modifies Windows registries and proxy setting allowing to set up a man in the middle attack.

FREE role-guided training plans

Get 12 cybersecurity training plans — one for each of the most common roles requested by employers.

Download Now

Md5 Signatures:

38abba51bdf98347fc4f91642b21b041

Possible Exploited Software:

PatchCcleanerPro.exe (suspicious since most triggered signatures are for this)

Signatures Triggered:

• ETPRO TROJAN Backdoor.Win32.DarkComet Screenshot Upload Successful
  					

Recommendations

There are various techniques by which you can defend yourself depending on the size of the organization. Including IDS and IPS for packet level analysis along with rugged firewall can prove to be a prominent mechanism. Also, establishing strong security policies and training in relevant areas is necessary apart from that below techniques:

• Restrict users from installing unlicensed or pirated products.
• Run up-to-date security software.
• Get the latest software updates.
• Turn on your firewall
• Limit user privileges
• Use caution with attachments and file transfers
• Use caution when clicking on links to web pages
• Protect yourself from social engineering attacks
• Use strong passwords.

References:

• https://www.virustotal.com
• https://blogs.msdn.microsoft.com/servergeeks/2014/07/12/dns-records-that-are-required-for-proper-functionality-of-active-directory
• https://www.microsoft.com/en-us/wdsi/threats/malware-encyclopedia-description?Name=HackTool:Win32/DarkComet
• https://www.hybrid-analysis.com/sample/8a972ffc82809f2338dd9f196633caeda4d9beb0a23d8f711e42f836a244b718?environmentId=100
• https://www.malware-traffic-analysis.net/
• https://www.windowscentral.com/how-to-keep-your-windows-pc-protected-against-malware
• http://www.urlvoid.com/
• http://www.ipvoid.com/
• https://www.hybrid-analysis.com/sample/8a972ffc82809f2338dd9f196633caeda4d9beb0a23d8f711e42f836a244b718?environmentId=100
• http://rules.emergingthreatspro.com/changelogs/archive/snort-edge.etpro.2015-08-21T22:34:40.txt
• https://virusscan.jotti.org/
• http://virscan.org/
• https://msdn.microsoft.com/en-us/library/ms675970(v=vs.85).aspx
• https://msdn.microsoft.com/en-us/library/ms675931(v=vs.85).aspx
• https://social.technet.microsoft.com/Forums/windowsserver/en-US/3b0419d0-619a-4828-bb97-05ddef56b2a9/krb5kdcerrpreauthrequired?forum=winserverDS