Skip links

Forensic investigation of a Social Engineering attack

Forensic investigation of a Social Engineering attack

In this article I am going to share with you a real Social Engineering attack , where we worked in a case to investigate if there was any forensic evidence to suggest that the laptop computer

a) had been compromised by the perpetrator(s),

b) if found to be compromised, how, when, and by whom it was compromised,

c) what malicious program was used in the compromise,

d) if the perpetrators used the workstation to launch attacks to other computers on the network, and

e) whether there was any forensic evidence to suggest the compromise lead to data exfiltration.

Incident Response

  1. Digital forensic analysis is a very comprehensive, time-consuming process. Hundreds of hours may be spent by an investigator on the in-depth examination of electronic evidence from a single device or even a single day’s worth of captured Internet traffic; however, this, in most instances, is not feasible due to realistic cost and time constraints. A detailed forensic investigation based on the needs of the client has been performed by Cyber Diligence. Additional forensic analysis may be carried out as requested by client.
  2. As part of our incident response, we have performed a highly detailed forensic analysis on the subject’s laptop. In addition to traditional analysis methods such as examination of the Windows Event Logs, Windows Registry contents, file folder creation, application execution evidence, keyword searches, etc., investigators performed additional steps to determine whether or not this computer was compromised.
  3. We have mounted the laptop’s forensic image as a disk partition to a forensic workstation and performed malware scans in order to reveal the presence of any malicious code on the device.
  4. Malware scans indicated the presence of two potentially malicious DLLs named “drprov.dll” and “acpage.dll.” The presence of a potentially malicious process named “ieinstal.exe” was brought to light; however, further analysis of the suspicious DLLs and processes revealed that they were false positives.
  5. In order to eliminate the possibility that the laptop may have been infected by a highly sophisticated ‘zero-day’ type of exploit — one that would not be detected by traditional analysis and scanning methods — we have cloned the original hard drive of the subject laptop then installed the forensic clone into the laptop and booted the laptop utilizing client-provided logon credentials in a sandbox with an inline Network Forensic Collector intercepting all network traffic. From July 23, 2017 to August 23, 2017, the HP Elitebook was ‘Sandboxed’ and allowed to run in a controlled environment. All inbound and outbound Internet connections and content were intercepted and analyzed. If the computer had fallen victim to any form of compromise that would allow the attacker(s) to gain access to it, the connection attempt would have been captured by the Network Forensic appliance. Detailed analysis of the captured network traffic revealed that there were multiple instances of suspicious connections and connection attempts, as can be seen below in Figure 1. For additional details see Exhibit 2.
1

Figure 1

6. Through the use of memory analysis tools, 5,681 DLL files and 95 executable (exe) were extracted from a RAM image of the HP Elitebook hard drive. The files were then processed in cloud-based malware scanning engines. As expected, there was a very small number of hits originating from the scanning processes. Further investigation revealed them to be false positives. The analysis did not reveal the presence of any malware.

7. We utilized Windows system tools to explore processes that are configured to automatically run on system startup, monitor all processes running in the system in order to detect suspicious activity, and monitor network activity for established connections. During live state analysis, we have observed the device attempting to make numerous connections to servers throughout the world and identified the process that was making the connection attempts.  

8. Additional forensic analysis was performed in an effort to identify potentially malicious files present on the drive. This step indicated the presence of a potentially malicious file named “2b2a83.bat.” Further analysis of the suspicious file was conducted using reverse engineering tools and techniques as detailed in the Malware Analysis section below.   

Malware Analysis

Overview

  • This section contains our analysis of malicious files which were found in both the hard disk and memory (RAM) of the infected system.
  1. During our initial analysis, we have identified an attack type known as ‘Fileless Malware’ wherein a hacker turns the victim’s operating system against itself without the need for installing additional software. This type of attack became popular during late 2014 with the emergence of malware families WMIGhost and Poweliks. These malware threats are difficult to detect and clean due to their use of unconventional locations for hiding their payloads. This is one of the main reasons why the malware, in this case, remained undetected for a year.
  2. Initial findings (JDSODM23 / emm string) led us to believe that the attack was somehow related to the malware known as Dark Comet RAT; however, after reverse engineering the malware in-depth, we have discovered that the malicious binaries were actually samples of the Kovter malware family.2.3.
  3. Kovter is a ‘Fileless Trojan’ which has been in the wild for over 2 years. It became popular with samples initially performing click-fraud on infected machines until samples were observed dropping Bitcoin Miner and Crypto Locker samples into victim PCs.

Persistence Mechanism

  1. The infected system had multiple LNK and BAT files which were located in the AppData and Startup folders. These folders are used by legitimate software and are accessible with the lowest system privileges as they do not require Administrator privileges. Most modern malware uses these locations for persistence/auto-start purposes. See Figure 2 below.
2

Figure 2

2. The target system had multiple instances of these files which indicates that the system was exposed to the initial attack vector more than once. The attack could have stemmed from a fake software update, Word documents containing malicious macros, or a cracked software.

3. Kovter uses a randomly generated file extension (331aa3f) for its persistence mechanism and registers this extension as an executable extension which allows the attacker(s) to take control whenever the associated file is executed. Having solely an executable extension is not sufficient for auto-startup. For this purpose, Kovter creates a BAT file at location C:\Users\A001372\AppData\Local\d0fb90\2b2a83.bat and drops a LNK file into %USER%\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup. See Figure 3 below.

3

Figure 3

4. Inspecting the registry, we have observed that the 331aa3f extension is merely a forwarder to the 33eb18 extension, which executes the malware regardless of the contents of the file with the 331aa3f extension. This explains the junk data which was observed in the randomly named file. See Figure 4 below.

 

4

Figure 4

Execution of Malware

  1. Whenever the system is rebooted, the following actions are performed:
    • LNK file is executed by the operating system from startup folder
    • LNK file executes the BAT file
    • BAT file starts the file which has the 331aa3f extension
    • The 331aa3f extension registry value forwards to the 33eb18 extension registry value
    • Shell->Open->Command is executed and first malicious script runs

This provides the malware with an opportunity to automatically start at system startup.

2. As can be seen in the image below, MSHTA is a legitimate Windows Executable which supports running JavaScript files. This feature is frequently exploited by malware authors and used for running encoded/encrypted malicious JavaScript files to serve as the initial starting point for malware. See Figure 5 below.

5

Figure 5

3 .In this incidence, MSHTA is run with the JavaScript command line parameter and executes the script seen in Figure 6 below:

6

Figure 6

4. This is an obfuscated JavaScript file that provides access to the WScript.Shell object, enabling the malware author to read any registry value. Kovter uses multiple encoded/encrypted registry values which can be seen in Figure 7 below:

7

Figure 7

8. Registry values ajel and zlrx are the most important of these values. The AJEL value is an obfuscated JavaScript file that is read by MSHTA and serves as the 2nd stage of the attack. This stage contains PowerShell scripts as well and reads the ZLRX registry value, which contains the last stage of an attack and injects this binary into a legitimate process (regsvr32.exe). This technique is referred to as ‘Reflective-PE’ and, like the previous techniques used by malware authors, is quite difficult to detect and stop.

9. The injection of a malicious binary into a legitimate process is known as ‘Process Hollowing/RunPE’ and can be easily spotted by a modern antimalware solution; however, Kovter uses a trickier technique and does not ‘unmap’ the main module of regsvr32.exe — which would allow antimalware solutions to flag the process as suspicious. Rather, it injects the malicious module into address 0x280000, and the legitimate regsvr32.exe is kept at address 0xA50000 and is not unmapped by the malware author. See Figure 8 below.

8

Figure 8

10. Most modern malware destroys the PE Header Information which is found at 0x280000 but this is not the case in this incident. The PE image at address 0x28000 is a Delphi compiled executable (MZ – Pascal); Delphi is a popular programming language among malware authors due to its extensive native support and no third party dependencies. See Figure 9 below.

9

Figure 9

11. Due to the suspicious string and a previous Kovter campaign which used the Dark Comet RAT, we had initially believed that the sample may have been injecting Dark Comet RAT into regsvr32.exe; however, further analysis pointed us in the right direction. See Figure 10 below.

10

Figure 10

12. Reverse engineering the malicious binary from its actual starting point at address 0x02DB25F, we have observed a reference to ‘LoadResource Windows API,’ which is used by a large percentage of malware for embedding configuration information after the malware is built and ready for a malware campaign. See Figure 11 below.

11

Figure 11

13. Dumping the malicious binary from memory, we were able to restore the ‘resources’ section of the malware, which appeared to be encrypted. See Figure 12 below.

12

Figure 12

13. Upon further inspection, we have identified the format of encrypted resource data as follows:

  • Offset 0x00: 16 bytes long encryption key in reverse order (highlighted in Figure 13 below)
  • Offset 0x10: RC4 Encrypted / BASE64 encoded configuration file
13

Figure 13

Configuration

  1. We were able to dump and decrypt this configuration section from the sample. This is the most important part of the analysis process and provides insight into what the malware is configured for.
  2. De-obfuscating and decrypting the configuration file with the 16 bytes key, we were able to see the list of ‘Command and Control (C&C) Servers’ the malware was using. See Figure 14 below.
14

Figure 14

3. This was the point in which we realized we were analyzing a Kovter sample.

4, The configuration file of the malware contained a total of 129 hardcoded command and control servers which are listed in Figure 15 below:

15
Forensic investigation of a Social Engineering attack 19

Figure 15

5. Although a majority of the C&C servers were dead, these servers were being used by the malware for grabbing click-fraud links, playing provided ads, and silently clicking the provided links in the background, as can be seen in Figure 16 below:

16

Figure 16

6. Though the malware is capable of running other malicious modules from its C&C server and acting as a remote backdoor, we have not observed such behavior during our ‘sandboxed’(virtual space in which the malware was run securely) analysis.

Conclusion

  • The victim machine is infected with a well-known malware sample, Kovter, which has been observed in the wild and is mostly used for click-fraud purposes. This malware family is hard to detect and clean due to usage of ‘Fileless Malware’ techniques which explains how the malware has become so widespread in 2017. Also worth noting is the malware’s capability of running another binary when instructed by the author, but we have not observed any such behavior.

Data Exfiltration Analysis

  • We performed forensic analysis focusing on evidence of data exfiltration once we identified the device as having been compromised in order to determine whether any data was extracted by the attacker(s). We continued to monitor Internet traffic to see if any attempt was being made to remove data from the network.  
  • System activities, user activities, active processes and related data, and network connections were all inspected using multiple forensic tools for evidence of data exfiltration. Each tool used in the analysis gave us a unique insight into the security environment of the system.
  • We conducted comprehensive forensic analysis for any evidence of data exfiltration by looking for any form of evidence that may be indicative of file upload activity to the cloud; examining file and folder access during off hours; checking for installation of software utilities that can facilitate file archiving and exfiltration; looking for suspicious HTTP, HTTPS, and FTP connections; running keyword searches and examining hits for relevancy to file exfiltration activity; and analysing Windows event logs to focus on critical times.

Summary & Findings

  • Our analysis of the subject device has concluded that there is indeed electronic evidence present on the subject device suggesting a breach. Malicious code we traced back to the Kovter family of malware was discovered and identified by investigators through the use of reverse engineering and forensic analysis. 
  • Detailed forensic analysis of the subject laptop as well as an examination of the compromised device’s behavior while in a sandboxed state did not uncover any evidence to indicate that any data was exfiltrated from the XYZ Corporation’s network. Furthermore, no forensic evidence suggesting the perpetrators have launched attacks to other computers from the compromised laptop was discovered.

This article has been taken from my Learn Social Engineering book, which was published by Packt. My book was selected as one of the Best Social Engineering Books of all time by Book Authority, which has been featured by Forbes, CNN, and other respectable media.

You can get your copy from Amazon : Foreword of the book was written by World Famous Troy Hunt , and many experts have contributed in the Ask The Expert section of the book like Marcus Murray , Hasain Alshakarti, Chris Jackson, Milad Aslaner, Yalkin Demirkaya, Arey Goresky, Prof. Dr, Mitko Bogdanoski, Ozan Ucar, Paula Januszkiewicz, Raif Saricia, Jonathan Trull,Emre Tinaztepe, Raymond Comvalious, Andy Malone, Sami Laiho, Dan Weis, Oguzhan Filizlibay , George Dobrea , Leyla Aliyeva, and Sukru Durmaz

Learn Social Engineering
Forensic investigation of a Social Engineering attack from real life – Social Engineering attack -Best Social Engineering Book- forensic-investigation-from-real-life- 
Explore
Drag