“Where’s the money?” Or, rather, “Where did the money go?” The user of a company-owned Windows 10 laptop fell victim of a cyberfraud attack. Or maybe the employee faked it and stole the money while pointing fingers to “evil hackers”? We’ll sure find out.
Background
The laptop in question runs Windows 10 and was a member of the corporate domain at the time of the incident. This same laptop was used as the employee’s main computer. The laptop could be used during business trips, work at home, and off premises via a corporate VPN.
By default, the local user was not granted administrative privileges. Domain security policies were enforced with a corporate password policy, BitLocker volume encryption, built-in firewall and UAC control. A major antivirus was running, and unrestricted Internet access was allowed. The computer belonged to the treasurer, whose duties included transacting and documenting with remote banking recipients.
The company that owned the laptop discovered unauthorized payments in one of its bank accounts, while all transactions appeared to be performed on behalf of legitimate users (the financial director and chief accountant). Significant sums have been transferred to unrecognized accounts in foreign banks. The organization’s security systems did not detect any suspicious activity at that time (all the IDS/IPS, SEIM/ERP, AV, WAF and other systems kept shut).
The investigator considered two possibilities. The first version was the attackers who had hacked the laptop remotely or gained physical access to it. The second version was insiders fraud and conspiracy. Can we solve the case?
WARNING
All tools and activities described in this article are for demonstration only. Improper use of the tools mentioned in the article can lead to the loss of information, alteration of data, and inadmissibility of collected evidence. Neither the author nor the editorial board can be held liable for any damages caused due to improper use of information provided in this article.Hypotheses
Initially, all we have are the above information and laptop seized from the treasurer immediately after the fraud discovery. There are two possible versions: (1) a conspiracy of managers who have disguised the theft as a hacker attack; or (2) unauthorized access of some hackers to the laptop. In the first case, it is necessary to search for artifacts and possible missteps made by negligence and allowing to trace the malefactors employed with the company. In the second case, it is necessary to search for remote hacking artifacts (i.e. neutralization of security systems, use of exploits, and malicious software remaining on the computer).
Defense programs installed on the laptop ensure the basic security level. This indicates that the hackers are skilled specialists. However, the computer could be taken out of the office and used outside the secure corporate domain. In other words, somebody could physically access the PC, dump all data stored on the hard drive (including the saved passwords, registry keys, etc.), and then ‘reflash’ the OS, thus, removing all traces of the crime.
Vulnerabilities and potential cracking scenarios
Here are some useful articles that may give insight into the possible hacking scenario:
- Excellent guides on PowerShell Payload and Metasploit Payload; and
- Fuzzbunch utility.
Laboratory setup
All actions taken to identify and extract artifacts remaining after a hacker attack can be divided into two large categories: (1) operations with volatile computer memory (RAM processes, network connections, etc.); and (2) operations with nonvolatile memory (HDD, removable storage devices, hidden and deleted files, alternative NTFS data streams, installed software, patched system libraries, etc.).
The number of available forensic tools is very large, but I will use at each stage only a few most popular utilities. Many of them are open-source or freeware, while others are commercial – but this is the way the things are done: specialized professional software costs money.
Windows 10 forensics
Since the release of Vista, many technical aspects in Windows (system registry architecture, event logging system service, etc.) have changed. As a result, guides written, for instance, for Windows XP are not applicable to later OS versions, let alone Windows 10 with its endless update packs.
Unlike earlier versions, Windows 10 has a number of additional data sources that can be used for artifact collection:
- Edge Browser – a successor to IE;
- Cortana – a virtual assistant supposed to become a new human-machine interface HMI;
- OneDrive – a file hosting and synchronization cloud service frequently used to store small backups of personal files and apps for Android mobile devices;
- Native Applications (Skype, Photo App, and Webcam App) – out of the box applications shipped with the OS;
- Taskbar – system notifications shown in the tray and informing you about programs running in the resident memory, applications running in the waiting mode, antivirus software, disabled firewall, etc.;
- Prefetch files – cache files storing information about frequently used applications in order to start them faster. This feature exists not only in Windows 10, but it also can be used for extraction of additional pieces of information.
After the release of Windows 7, Microsoft has compiled a checklist of main artifacts and their sources that can be used by forensic experts. Such catalogues, entitled Windows Jump Lists, are currently available both for Windows 7 and Windows 10.
WWW
Below are some useful resources on Windows 10 forensics:- Windows 10 Forensics – a presentation briefly describing some artifact collection procedures for Windows 10;
- Windows 10 Forensic Analysis – a book by Rhys P. J. Evans; and
- Windows 10 Forensics (Center for Digital Investigation) – a small but informative brochure.
Forensic analysis checklist
To locate and extract forensic evidence, we are going to check the following items:
- RAM (system and user processes, imported DLL files associated with system and user processes, third-party or nonsystem services, and running malicious code);
- HDD (deleted partitions, defined partitions, deleted files, shadow copy snapshots, RAW (i.e. unallocated disk sectors), Recycle Bin ‘scraps’, LNK and Notification shortcuts, installed software, downloads, etc.;
- network stack (established connections, open ports, ‘unknown’ services on ports, and parasite outgoing traffic);
- system registry (installed and uninstalled software, temporary shortcuts, file associations, etc.);
- system journals (logon, privilege escalation, access to folders, changes in the domain group policy, account creation/deletion, and system crashes and restarts);
- pagefile and hibernation files (some data in these files are preserved in their original state); and
- application data (Skype, OneDrive, Xbox), mail, and browsers (browsing history, bookmarks, downloads, and potentially passwords).
Imaging HDD of the hacked system
First, let’s dump the entire hard drive of the hacked laptop. This step protects us from accidental mistakes (that may cause destruction of some artifacts), produces a reference copy of the system at the beginning the forensic analysis, and creates an image suitable for deeper research but not requiring physical access to the analyzed PC. To image the hard drive, we are going to use Forensic Toolkit Imager (FTK Imager).
The program is available on its official website and in specialized DEFT and CAINE (Computer Aided Investigative Environment) distributions. For more information on imaging and other utilities, see the case study Forensic Images: For Your Viewing Pleasure published by SANS Institute. For those having not much time for reading, I suggest the illustrated Step by Step Tutorial of FTK Imager, a clear and straightforward guide.
The toolkit comes in two versions: CLI (Command Line Interface) and GUI (Graphical User Interface). The both versions are run on a working computer with the loaded host OS. The third option is safer: the HDD image is created without loading the host OS (to be addressed in more detail later).
Let us begin with the first variant. We open the analyzed laptop, remove its HDD, connect it to our laboratory PC, launch FTK Imager in the console mode, and start entering commands:
Type in the CLI interface:
E:\>ftkimager.exe e:\ --e01 --frag 2G --compress 9 --verify
In this particular case, the line looks as follows:
E:\>ftkimager.exe \\.\PhysicalDrive0 e:\IMAGE_FORENSIC\filename --e01 --frag 2G --compress 9 --verify
If everything was done right, we should see the following picture:
Those preferring graphical interface have to take more steps. To create a disk image, go to File → Create Disk Image.
Select “Physical Drive”.
If there are several disks in the system, select the system disk.
Do not forget to checkmark “Verify images after they are created”.
Now it is time to define the format of our image. For better compatibility with the forensic software, select the default variant – E01.
The third dumping option allows to create an image without loading the host OS: the information is dumped in the Live CD mode. This is the safest and preferable method: we do not interfere in the current system configuration (i.e. don’t gain administrator rights, fill the system log with unnecessary information, etc.). More importantly, this method preserves artifacts remaining after the hacking. For instance, is some malware was used in the attack, it may destroy all traces (i.e. clean up logs and the %TEMP% directory, delete its own executable file, etc.) at a timer’s signal or after a certain event , thus, significantly impeding the investigation.
For this purpose, we are going to use specialized CAINE Linux distribution. All actions are performed in the terminal window. We connect an external hard drive to the analyzed laptop and concurrently boot it up from a USB stick with CAINE. Then we mount the external HDD (/dev/sdb1) in a temporary folder:
root@caine:~# mkdir /mnt/target
root@caine:~# mount /dev/sdb1 /mnt/target
Creating hash of the laptop’s hard drive (/dev/sda) using MD5 algorithm:
root@caine:~# md5sum /dev/sda > /mnt/target/HDD_Img_Forensic.md5
Using the dd utility to dump the /dev/sda disk to the /mnt/target folder under the name HDD_Img_Forensic:
root@caine:~#dd if=/dev/sda of=/mnt/target/HDD_Img_Forensic.img conv=sync,noerror bs=8k
And finally, verifying the created image by its MD5 hash sum – just to make sure that the disk was successfully dumped:
root@caine:~#md5sum /mnt/target/HDD_Img_Forensic.img > /mnt/target/HDD_Img_Forensic.img.md5
root@caine:~# cat /mnt/target/*.md5
Prior to turning the laptop off, it is necessary to unmount the temporary directory:
root@caine:~# umount /mnt/target/
Dumping RAM of the studied laptop
After dumping the hard drive, it is necessary to perform the same operation with the RAM: it may contain plenty of artifacts, especially when it comes to infection or alien software installation. For this purpose, we are going to use two similar tools: DumpIt from Comae Memory Toolkit and Belkasoft RAM Capturer. The obtained .mem images can be opened for parsing in Volatility, Rekall, or Belkasoft Evidence Center.
Making the first dump with DumpIt.
Making the second dump with Belkasoft RAM Capturer.
Now it is time to open the obtained RAM dump in Belkasoft Evidence Center.
The HDD images obtained at the first stage of our investigation can be mounted using Arsenal Image Mounter.
Searching for artifacts
First of all, we need to get some information on the user profile using the ForensicUserInfo utility. It extracts the RID system information, account expiry date, password change date, LM/NT hash, number of logins to the system, dates of failed login attempts, existing groups, and paths to the user profile.
To review the list of user and system processes, launch the tasklist utility in the Command Prompt (CMD):
c:\>tasklist
– display all processes in the current window;c:\>tasklist /svc
– display all services running in the system;c:\>tasklist > c:\processes_list.txt
– export the process (service) data to the file processes_list.txt.
Another possible way is to use an alternative task manager, for instance, AnVir Task Manager or Process Explorer.
Now it is time to use a few special forensic utilities included in the Sleuth Kit.
To see the available information on the memory, type the mmstat
command.
We know the system volume type, and the mmls
command makes it possible to view unallocated sectors on the disk:
mmls -t dos X:RAM_Img_Forensic.E01
Then we can use FileName Layer Tools to view deleted files and unallocated segments.
fls -o 1435648 X:RAM_Img_Forensic.E01
What’s next? Using the fls utility, we create a bodyfile – an intermediate file required to build a timeline of the file activity. To record the collected data in bodyfile.txt
, type:
fls -r -m "/" -o 1435648 X:RAM_Img_Forensic.E01 > bodyfile.txt
After the creation of bodyfile.txt
, we can use the mactime
utility and build a timeline of the file activity (file creation, deletion, and renaming) in the system that can be exported in an Excel-like form:
mactime.pl -b bodyfile.txt -d > timeline.csv
Below is a summary datasheet for Sleuth Kit utilities:
- mmstat – general information on the system volumes, including partition tables and disk labels;
- mmls – information on the used space, deleted, and allocated files;
- fsstat – information on the file system, including the volume serial number, ID, cluster size, etc.;
- fls – search for allocated and recently deleted files, either in a specific folder or on the entire disk;
- mactime – create a timeline of the file activity based on the data collected with fls.
Let us try to find recently deleted files – or whatever remains from them – using the Autopsy utility shipped with the Sleuth Kit.
It would be also a good idea to check for files saved in Windows shadow copies using the ShadowCopyView utility developed by NirSoft.
The next step is registry analysis. Let’s perform it using three tools: Windows Registry analysis included in Magnet AXIOM pack, RegRipper, and Registry Explorer.
To view uninstalled software, open the database file NTUSER.DAT in Registry Explorer and check the following hive:
NTUSER.DAT\SOFTWARE\Microsoft\UserData\UninstallTimes
If the treasurer had used IE, we can also view saved URLs:
NTUSER.DAT\SOFTWARE\Microsoft\InternetExplorer\TypedURLs
Furthermore, we can try to retrieve passwords if the user has enabled autosaving of account credentials (i.e. login and password):
NTUSER.DAT\Software\Microsoft\Internet Explorer\IntelliForms
Researcher’s datasheet: places of interest in the registry
The path to the list of most recently used (MRU) files is as follows:
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\RunMRU
Globally Unique Identifiers (IDs) containing encrypted records of each OS object, application (program), or executable .exe file run by the user are stored in the following hive of the registry:
HKEY_CURRENT_USER\Software\Mcirosoft\Windows\CurrentVersion\Explorer\UserAssist
The list of IDs and respective software is available here.
All USB devices ever connected to the computer are recorded in a special hive:
HKEY_LOCAL_MACHINE\System\ControlSet00x\Enum\USBSTOR
The thread below stores all wireless networks (Wi-Fi SSID) the computer was ever connected to:
HKEY_LOCAL_MACHINE\Software\microsoft\WZCSVC\Parameters\Interface
For those willing to discover more exciting places in the registry, I recommend an article entitled Forensic Analysis of the Windows Registry.
Network stack
To quickly view network connections, we can use the netstat shell command:
netstat -a
In this program output, the following statuses are of utmost interest:
- CLOSED – connection closed, socked not in use;
- LISTEN (LISTENING) – waiting for incoming connections;
- ESTABLISHED – connection established (data transfer is ongoing).
Below are some additional output options:
// List TCP connections
netstat -at
// List UDP connections
netstat -au
// List all ports open for incoming traffic
netstat -n
A similar output can be viewed graphically using TCPViewer.
There is one more specialized forensic tool – NetworkMiner. In addition to features present in the above programs, NetworkMiner extracts files from FTP, TFTP, HTTP, SMB, SMB2, SMTP, POP3, and IMAP traffic; extracts X.509 certificates from SSL encrypted traffic; decapsulates GRE, 802.1Q, PPPoE, and VXLAN; supports the geo IP localization function; and exports results to CSV, Excel, XML, CASE, and JSON-LD.
Analyzing Recycle Bin
It is no secret that some data moved to the Recycle Bin can still be viewed, even if the files had been deleted (i.e. the Recycle Bin was ’emptied’). For this purpose, we are going to use a large pack entitled EnCase Forensic.
Time has come to analyze logs (system journals). This requires the FullEventLogView tool developed by above-mentioned NirSoft and Magnet AXIOM for computers.
We are primarily interested in the following events:
- Account Logon – a domain user account is authenticated on a domain controller;
- Account Mgmt – changes in an account (added to a group, renamed, permissions or rights granted, etc.);
- Logon Events – logging into an account and logging out of it;
- Directory Service – adding objects from Active Directory;
- Object Access – audit of any and all attempts to access files and other Windows objects;
- Policy Change – changes in the security policy;
- Privilege Use – execution of commands on behalf of the administrator or another privileged user;
- Process Tracking – tracking events associated with system processes; and
- System Events – OS boot-ups and shutdowns, including crashes.
A more detailed list of security events and their IDs can be found on GitHub.
The next step is LNK file analysis (i.e. searching for shortcuts to programs that were installed, run, or subsequently removed). Above-mentioned EnCase Forensic tool will assist in this.
Finally, we are going to scan once again User Apps embedded into the system: Skype, OneDrive, and Edge. Above-mentioned Belkasoft Evidence Center is used to extract data from the Edge browser and paging file Pagefile.sys.
Normally, Skype stores profiles with useful information in the following directory:
C:\Users\%USERNAME%\AppData\Roaming\Skype\
However, it is always a good idea to search the entire HDD for Skype folders because the messenger could be installed in a custom directory or run as a portable version.
Belkasoft Evidence Center extracts valuable data from the profile file, including SQLite databases and unallocated space, and synchronized files from chats, pagefile.sys
, and hiberfil.sys
. Its developer, NirSoft, has also created another excellent utility: SkypeLogView.
You might be surprised, but we can extract from Windows-based systems even the system tray notification history; it is stored in the following directory:
C:\Users\Username\AppData\Local\Microsoft\Windows\Notifications
The name of the database storing the notification history may differ on various machines – it depends on some internal parameters (the file extension may be different from .db). To open it, use SQLite manager. After launching it, find .db files in the folder:
C:\Users\Username\AppData\Local\Microsoft\Windows\Notifications
Add the found files to the manager, and the embedded viewer window will pop-up.
Cortana voice assistant also has a database storing its history; it is located in the folder:
C:\Users[User]\AppData\Local\Packages\Microsoft.Windows.Cortana_xxxx\LocalState\ESEDatabase_CortanaCoreInstance\CortanaCoreDb
Speaking of OneDrive, if the synchronization (e.g. with an Android smartphone) was enabled, then some files can be found in the gadget using the following path:
/mnt/sdcard/Android/data/com.microsoft.skydrive
The logon/logoff, synchronization, and other logs may be stored in text files located in the directory:
C:\Users\\AppData\Local\Microsoft\OneDrive\logs
Investigation findings
We have collected all available information – so, what conclusions can be drawn from it?
In the system directory storing Shadow Copies, we have found inter alia an unknown executable file; it turned out to be malware designed to steal logins, passwords, characters entered from the keyboard, clipboard data, and cookie files. Interestingly, this file was not detected by the installed antivirus. It was also found that several connections to IP addresses located in Western Europe are not typical for the software installed on the analyzed computer. Based on the remote banking logs, it was established that somebody has logged in to the system during the lunch break – at that time, the treasurer (i.e. the primary user of the corporate laptop) was not in the office and, accordingly, could not perform these operations. However, the treasurer made a severe mistake by leaving the USB key with the electronic signature plugged into the computer.
Jointly antivirus analysts, we recreated the possible hacking scenario.
A week before the incident, the laptop was submitted to the technical support for software updates and performance optimization. At that time, the malicious code was installed on the computer and added itself to the startup. Within a week, the malware was recording all data entered from the keyboard; in addition, it dumped the registry, analyzed the user activity during the workday, and transmitted this information to the malefactor’s server. Then the program, acting as a dropper, has downloaded backdoor components and installed a encrypted network tunnel to the victim’s computer. Apparently, the malicious code used a special option: encapsulated data transmission in the DNS protocol.
On the day of the incident, the treasurer went on the lunch break, and the hacker connected to the infected PC. The attacker logged in to the remote banking system using keys with electronic signatures stored on the plugged USB token and made the transactions. Then the thief covered up the traces by removing the malware and backdoor modules from the system and cleaning up the %TEMP%
folder and some security and user logs (the malefactor’s permissions were not sufficient to clean up all of them).
As is known, accounting systems are pretty inert; therefore, the corporate security service became aware of the incident only two days later – by that time, the thieves have already cashed the transferred funds. However, artifacts left on the turned off laptop made it possible to reconstruct the crime (even though the money could not be recovered).
Conclusions
Our investigation is completed. Now you are familiar with the basic forensic utilities. Should a real hacking incident occur, you may examine the cracked machine using these tools, collect artifacts, and reconstruct circumstances of the attack. The next step – parsing of the malware and backdoor used for the unauthorized connection and theft of remote banking credentials – will likely make it possible to identify the perpetrators. Also, you got an idea of the everyday work of forensic experts who painstakingly collect tiny bits and pieces of information to solve cybercrimes.