Harlan Carvey, in
Windows Registry Forensics (Second Edition), 2016 One of the things I really like about digging into the Registry is the amount of information that is available, often
times even after a user or intruder has taken “antiforensics” steps in order to hide their activities. Often users and intruders will take steps to cover their tracks and remove indications of their activities without realizing that their interactions with the operating system (and often times, with applications) are being “recorded” automatically. For example, I was examining a system about a year ago which had been found to be infected with a particular
variant of a remote access Trojan (RAT). This particular RAT variant is usually installed as a Windows service, allowing the intruder to access the system with privileges greater than that of the system administrator. Further, this particular bit of malware is most often assumed to be installed via a “spearphishing” e-mail, in which the user is enticed to click on a link or malicious document, resulting in the installation of the RAT. In this particular case, Registry artifacts
revealed that the RAT had been installed as a result of someone with physical access to the system plugging a USB thumb drive into the system (it was mounted as the E:\ volume) and launching an installer application. When the user’s employer requested that they turn in the system for examination, the user attempted to remove the RAT…in fact, artifacts in the Registry revealed that the last key in focus in the Registry Editor before it was closed by the user was the key alphabetically following
the name with which the RAT was installed. Additional information was extracted from the hibernation file through the use of the Volatility Framework, but the preponderance of artifacts extracted from the Registry clearly indicated that the RAT was installed and running on the system with the full knowledge (and involvement) of the user. As I’m writing this section of the book, I’m working (as part of my day job) on an examination in which an intruder had
access to an infrastructure via domain administrator credentials and Terminal Services. I’d tried to backtrack the intruder’s connections as they hopped from system to system, but they had a penchant for clearing the Windows Event Logs on some (albeit not all) systems. Even though I could not see all of the data that I wanted to, there was more than enough data in the Registry to tell me when they were logged into the system and active (days and
times), as well as other systems to which they connected. Even without the Windows Event Log records, I was able to build a time-based map of the intruder’s activities, showing what time of day they were active, files and resources they’d accessed, etc. I was also able to illustrate their connection to a file transfer protocol server. Data available in the Registry can be very revealing on a number of fronts. Although the intruder had cleared the Windows
Event Log and we were not able to see where they were when they logged into the system we were examining, but we could see when they were active on the system (which we could then correlate with other sources, such as domain controller and VPN logs), what they’d done, and other systems they’d connected to through the use of the Terminal Services Client as well as via Microsoft networking. All of this data remained even following the intruder’s “antiforensics” steps.Registry Analysis
Remnants
Read full chapter
URL: //www.sciencedirect.com/science/article/pii/B9780128032916000012
Processes and Tools
Harlan Carvey, in Windows Registry Forensics (Second Edition), 2016
Memory
I know I said that this chapter focused specifically on “dead box” analysis and that remains true…even though we’re now going to discuss accessing Registry information in memory. The fact is that I’ve conducted analysis of a good number of images acquired from laptops where the hibernation file has proved to be extremely valuable. In one particular instance, I was able to determine that a particular remote access Trojan (RAT) was running on a system when the hibernation file was created, allowing me to see that it was running at one point. This was important, because analysis of the rest of the acquired image indicated that not only had the user installed the RAT from a thumb drive, but that same user had also removed the RAT files and its persistence mechanism as well.
There are a number of Volatility plugins available for parsing memory dumps for Registry data. The command reference for those plugins can be found online at //code.google.com/p/volatility/wiki/CommandReference#Registry. Using these plugins, you can list available hives, dump individual hives, print the contents of arbitrary keys, or dump a user’s UserAssist key entries (the UserAssist key entries will be discussed in more detail in chapter Case Studies: User Hives). Even if there isn’t a plugin available to pull specific information that you’re interested in from within a memory dump or hibernation file, you can always extract the hive file (or files) you’re interested in and use other tools to view the file or parse out specific keys, values, or data. On September 25, 2012, the Volatility team posted an article on their blog that described, in part, a shellbag Volatlity plugin that would parse shellbag entries from memory, comparing that to the output of the printkey plugin. That blog post can be found online at //volatility-labs.blogspot.com/2012/09/movp-32-shellbags-in-memory-setregtime.html. This topic is also covered on pages 299 and 300 of the book, The Art of Memory Forensics (information about the book can be found online at //www.memoryanalysis.net/#!amf/cmg5).
Read full chapter
URL: //www.sciencedirect.com/science/article/pii/B9780128032916000024
Common Botnets
Craig A. Schiller, ... Michael Cross, in Botnets, 2007
SDBot
The SDBot family of bots has been around for almost five years and has grown to include hundreds of variants and offshoots. One of the elements that has added to the longevity of the SDBot family is that the original developer essentially made it into an open-source malware program. The original SDBot author released the source code for the bot and included his contact information, providing a means of public collaboration and evolution to continue developing and improving the code.
The other key to the success of SDBot is poor security on the compromised systems. SDBot relies on spreading itself primarily via network shares using blank or common passwords. Systems with solid security and more complex passwords will not be compromised by SDBot.
With so many variants, a comprehensive description of each would require a book of its own. The following are the general details of how SDBot works and propagates and how you can recognize common signs that could indicate that your computer has been compromised by SDBot.
Aliases
Antivirus and security vendors rarely agree on naming conventions, so the same threat can have multiple names, depending on which vendor is supplying the information. Here are some aliases for SDBot from the top antivirus vendors:
▪McAfee: IRC-SDBot
▪Symantec: Backdoor.Sdbot
▪Trend Micro: BKDR_SDBOT
▪Sophos: Troj/Sdbot
▪Kaspersky: Backdoor.IRC.Sdbot
▪CA: Win32.SDBot
Infection
The method of infection varies from one variant to the next, but SDBot traditionally takes advantage of insecure network shares or uses known vulnerability exploits to compromise systems. Once SDBot is able to connect to a vulnerable system, it will execute a script that will download and execute SDBot to infect the system.
SDBot typically includes some sort of backdoor that allows an attacker to gain complete access to compromised systems. The Remote Access Trojan (RAT) component of SDBot connects to an IRC server and lies silently waiting for instructions from a botherder.
Using the RAT, a botherder can collect information about the compromised system, such as the operating system version, computer name, IP address, or the currently logged-in username. A botherder can also run IRC commands directing the compromised computer to join an IRC channel, download and execute files, or connect to a specific server or Web site to initiate a distributed denial-of-service (DDoS) attack.
Signs of Compromise
If you believe that your computer might be infected with SDBot, there are a few clues you can look for to verify your suspicions.
Upon execution, SDBot will place a copy of itself in the System folder. Typically, this folder is C:\Windows\System32, but SDBot uses the %System% variable to find out where it is and then places a copy of itself in that folder. The filename used can vary, but Table 4.1 contains a list of known filenames.
Table 4.1. Known Filenames Used by Backdoor*
| Aim95.exe | service.exe |
| CMagesta.exe | sock32.exe |
| Cmd32.exe | spooler.exe |
| Cnfgldr.exe | Svchosts.exe |
| cthelp.exe | svhost.exe |
| Explorer.exe | Sys32.exe |
| FB_PNU.EXE | Sys3f2.exe |
| IEXPL0RE.EXE | Syscfg32.exe |
| iexplore.exe | Sysmon16.exe |
| ipcl32.exe | syswin32.exe |
| Mssql.exe | vcvw.exe |
| MSsrvs32.exe | winupdate32.exe |
| MSTasks.exe | xmconfig.exe |
| quicktimeprom.exe | YahooMsgr.exe |
| Regrun.exe |
Source: Symantec Corp. (www.symantec.com/security_response/writeup.jsp?docid=2002-051312-3628-99&tabid=2)
Copyright © 2002
SDBot also makes modifications to the Windows Registry, aimed primarily at making sure that the SDBot software is automatically started each time Windows is booted up. Typically, one of the Registry values displayed in Table 4.2, or something similar, is added to one of the following Registry keys:
Table 4.2. Registry Values Used by SDBot*
“Configuration Loader” = “%System%\iexplore.exe”
“Configuration Loader” = “MSTasks.exe”
“Configuration Loader” = “aim95.exe”
“Configuration Loader” = “cmd32.exe”
“Configuration Loader”= “IEXPL0RE.EXE”
“Configuration Manager” = “Cnfgldr.exe”
“Fixnice” = “vcvw.exe”
“Internet Config” = “svchosts.exe”
“Internet Protocol Configuration Loader” = “ipcl32.exe
“MSSQL” = “Mssql.exe”
“MachineTest” = “CMagesta.exe”
“Microsoft Synchronization Manager” = “svhost.exe”
“Microsoft Synchronization Manager” = “winupdate32.exe”
“Microsoft Video Capture Controls” = “MSsrvs32.exe”
“Quick Time file manager” = “quicktimeprom.exe”
“Registry Checker” = “%System%\Regrun.exe”
“Sock32” = “sock32.exe”
“System Monitor” = “Sysmon16.exe”
“System33” = “%System%\FB_PNU.EXE”
“Windows Configuration” = “spooler.exe”
“Windows Explorer” = “ Explorer.exe”
“Windows Services” = “service.exe”
“Yahoo Instant Messenger” = “Yahoo Instant Messenger”
“cthelp” = “cthelp.exe”
“stratas” = “xmconfig.exe”
“syswin32” = “syswin32.exe”
*These registry values are used to modify the Windows registry so that SDBot is started when Windows starts.Source: Symantec Corp. (www.symantec.com/security_response/writeup.jsp?docid=2002-051312-3628-99&tabid=2)
Copyright © 2002
▪HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Run
▪HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\RunServices
▪HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run
Source: Symantec Corp. (www.symantec.com/security_response/writeup.jsp?docid=2002-051312-3628-99&tabid=2))
Some variants of SDBot can also create new files in the %System% directory for additional functionality. Two files that have been identified from known SDBot variants are SVKP.sys and msdirectx.sys.
The SVKP.sys file is a component of SVK Protector, a copy protection utility that prevents the software from being reverse-engineered. Some variants use this technique in an attempt to prevent security researchers or antivirus firms from being able to analyze the malware and determine how it works.
Msdirectx.sys is designed to provide rootkit functionality for the software and allow an attacker to gain complete access and control of the target system without being detected.
Another sign that might identify an SDBot infection is open ports or unexpected network connections on your system. Some variants of SDBot will establish an IRC connection via TCP port 6667, and others have been known to use port 7000.
Are You Owned?
Windows comes with a built-in command-line utility that you can use to see what ports are active on your system. Click Start | Run and type cmd, then press Enter. At the command prompt, type netstat –a followed by pressing Enter to get a complete listing of the open ports on your system and the current state of communication.
For more information about the features of netstat, you can also type netstat /? to find out what other switches are available and the functions they perform.
If you are really paranoid that your system could be compromised, even the netstat utility could be called into question. Perhaps the malware has replaced it with a modified or malicious version. If you are concerned that this might be the case, you can use nmap from a remote system and scan the suspected computer for open ports instead.
The SDBot program might attempt to communicate with a variety of IRC channels using its own IRC client software. Some examples of IRC channels used by known SDBot variants are:
▪Zxcvbnmas.i989.net
▪Bmu.h4x0rs.org
▪Bmu.q8hell.org
▪Bmu.FL0W1NG.NET
Propagation
To spread effectively, SDBot relies on weak security on target systems or the ability to leverage the current user credentials to connect with other network resources. SDBot assumes the same access rights and privileges as the user that is currently logged into the system.
SDBot will attempt to connect to and spread via default administrative shares found on a typical Windows system, such as PRINTS, C$, D$, E$, ADMIN$, or IPCS. Some variants come bundled with a listing of common username and password combinations, such as abc123 or password for the password, which can be used to attempt to connect with network resources as well.
Variants of SDBot are also known to scan for Microsoft SQL Server installations with weak administrator passwords or security configurations.
Read full chapter
URL: //www.sciencedirect.com/science/article/pii/B9781597491358500068
Layer 8: The People Layer
In Hack the Stack, 2006
World Wide Web, E-mail, and Instant Messaging
Internet technologies can inadvertently aid scams. The simplest attack is to spoof the sender’s address in an e-mail message. A recipient with little knowledge may not notice phony headers that were inserted to make a message look legitimate. A truly knowledgeable recipient can easily tell when headers are phony.
Trojan Horses and Backdoors
In another scam, the attacker sends a Trojan horse, which is a benign program that carries a malicious program. The benign program usually appears as something entertaining (e.g., a game, electronic greeting card, and so forth), and works as advertised so that the recipient is not suspicious. The benign program also contains a wrapper program that launches both the benign program and a malicious program. The malicious program might vandalize the recipient’s system, or it might create a backdoor to the system, which is a means for gaining access to a system while circumventing identification and authentication. Backdoors introduced through Trojan horses are known as remote access Trojans (RATs). Typically, a RAT makes entries in the registry or configuration files of the operating system, so that it is initialized every time the system is booted.
Disguising Programs
Another trick used to get targets to accept malicious attachments is to disguise programs. A feature of Windows that hides the filename extension is controlled from Windows Explorer | Tools | Folder Options… | View | Hide. The default setting in Windows XP is to hide these extensions. Knowing this, the attacker can create a malicious program and name it syngress.jpg.exe or something similar. When Windows hides the .exe filename extension, syngress.jpg appears to have a filename extension, but is considered to be a filename without an extension. Because the bogus extension does not indicate an executable file, the recipient feels safe in opening it. The recipient would have been safer if he or she didn’t download any attachments he or she wasn’t expecting.
Tip
If your e-mail program doesn’t automatically scan attachments for viruses, be sure to individually scan each file with an antivirus program before opening the file.
Phishing
Another attack that combines social engineering and technology is called phishing. In this type of attack, an e-mail message is sent that appears to be from a company that the recipient has an account with (see Figure 9.9). The message contains some pretext for needing the recipient’s account identification and authentication credentials (usually a password). The pre-text could be that a computer glitch caused the information to be lost, or that fraudulent activity occurred on the account. In order to verify the recipient’s account, the target is asked to click on a hyperlink in the e-mail message. The displayed address looks like a legitimate address, but the actual address links to the attacker’s Web site, which is where the target enters his or her account information and the attacker captures it.
Figure 9.9. E-mail Phishing Message
If a Web address is long, only a portion of it is displayed on the status bar. A Uniform Resource Locator (URL) can include a User ID for a Web site that requires authentication and would take the form [email protected]/page. If the banks domain name is used as a user ID, the URL would look something like [email protected]/page.
If just the first part of the URL appears in the status bar, the recipient sees what looks like a legitimate Web address, and will feel secure clicking on the hyperlink. The attackers Web site doesn’t require authentication and will ignore the user ID.
Tip
Think you can spot a phishing attack? Test yourself at //www.survey.mailfrontier.com/survey/quiztest.html. Never click on a link to one of your 22 personal accounts. Always type the URL manually.
Domain Name Spoofing
One type of domain name spoofing involves gaining sufficient privileges on the domain name system (DNS) in order to change the resource records in its database. If an adversary changes the address record so that it associates the adversary’s IP address with the legitimate domain name, any computer requesting resolution of that domain name will be directed to the adversary’s computer. This is called pharming, and its effectiveness derives from the fact that the target is surfing to a legitimate domain name. If the DNS server belonging to the domain is altered, everyone on the Internet will receive the adversary’s IP address when resolution of the domain name is requested. If the DNS server of the target’s company is altered, only users in the target company are fooled. The company DNS server maintains a cache of the answers it gets from other DNS servers in case another user in the company requests the same information. By poisoning the cache, all users in the company receive the adversary’s IP address when they request resolution of this domain name.
The attack can also be brought down to the level where it only affects one user. Every IP-enabled client computer has a hosts file where the user can hard-code the association between a domain name and an IP address. By poisoning this file, the user of the affected computer goes to the adversary’s IP address specified in the file, whenever he or she surfs to that domain.
Another trick used to make a bogus URL look legitimate is to use a domain name that appears to be the bank’s domain name, but actually contains characters from another language’s alphabet with a similar appearance. This is called International Domain Name (IDN) spoofing (also known as a homograph attack). For example, the Cyrillic alphabet used in the Russian language has some characters in common with the Latin alphabet. Therefore, an attacker could use a Cyrillic “a” instead of a Latin “a” in the domain name for bank.com. To the eye, it’s the correct domain name, but it’s actually different. For more information, see //www.en.wikipedia.org/wiki/IDN_homograph_attack.
Secure Web Sites
Web site operators maintain user confidence that a site is legitimate and secure, by obtaining a certificate that proves that a Web site’s public encryption key belongs to the domain name of that site. The Web site owner obtains the certificate, because he or she is required to demonstrate proof of identity to the CA. Any user can determine the authenticity of a certificate using his or her Web browser software. But there is a vulnerability.
An attacker can perform a Man-in-the-Middle (MITM) attack (i.e., intercept communications between a user and a Secure Sockets Layer (SSL)-protected Web site), but because the communications are secured with SSL, the intercepted information would not be readable. An attacker could replace the certificate offered by the Web site with his or her own certificate and send it to a user, but the certificate would have problems. The attacker’s certificate could be for the wrong domain name, or it could have the correct domain name but not be issued by a known or trusted Certificate Authority (CA). Either way, the Web browser will issue a warning that the certificate has problems with the legitimate Web site.
Most users would not know what to do if informed that the domain name on the certificate didn’t match the domain name of the Web site. However, once users become inured to these mistakes, they are less likely to heed the warning and more likely to click OK.
Another approach for the attacker is to create his or her own certificate instead of buying a legitimate one. It’s virtually impossible to create a certificate that looks legitimate, because the attacker doesn’t have the CA’s private key that is required to digitally sign a certificate. A digital signature is created using a private key and the document to be signed. On any other document, the signature would be detected as a forgery. However, if the attacker makes up a convincing name of a CA that he or she controls, the digital signature on the certificate will belong with that certificate. The only problem is that the identity of the attacker’s CA is unknown to the browser, and therefore, the browser warns the user that there is no root certificate for the signer of this certificate.
If the attacker gets the user to accept the phony certificate, the user will encrypt his or her communication with a key that is only known to the attacker. The attacker can then decrypt and read the message and then re-encrypt it with the Web site’s own key. The attacker can now eavesdrop on the communications or modify the decrypted message before re-encrypting it.
Tip
Don’t log on to your computer with the administrator’s ID to go Web surfing. If you reach a malicious Web page, the malware on that page will have full privileges over your computer. Use a user ID with low privileges so that a successful attack on your computer won’t have the privilege level needed to compromise your operating system.
Read full chapter
URL: //www.sciencedirect.com/science/article/pii/B9781597491099500137
Software problems and solutions
John Sammons, Michael Cross, in The Basics of Cyber Safety, 2017
Malware and Viruses
Malware is a term that’s short for malicious software and describes any type of code that’s designed to compromise the functions of a computer by bypassing access controls, stealing, and\or damaging data, or otherwise disrupting its normal operations. Note that we said that it’s designed for this purpose. If you install a bad piece of software (such as a buggy update) that causes problems on your computer, this doesn’t necessarily make it malware. After all, software developers are humans, and humans make mistakes. What makes it malware is that the software was designed with a malicious intent and/or with the purpose of causing that problem.
The other thing to understand about malware is that it’s an umbrella term, used to describe a number of different software threats. One type of malware you’ve probably heard of is a virus. A virus is a type of program or code that spreads from one system to another by attaching itself to other files. When you open a document, execute a program, or run a script file that’s been infected with a virus, it often makes a copy of itself and can attach itself to other files on your system. When you share one of those files with other people, such as by sending an infected document as an attachment via email or saving it to a network where someone else can open it, other computers then become infected. Code in the virus determines what the virus will do to a system, inclusive to damaging data or stealing information.
When you hear people talk about viruses and malware, they often use the words interchangeably, but that’s not the case. Viruses have been around for decades, gaining significant media attention in the 1990s when the Internet became commercial and people first began using it on home PCs. The term was seared in the public mindset and people began to refer to any kind of malicious software threat as a virus. While they’re still a real danger to your computer, there are many kinds of malware that are not viruses. Now that you have a good understanding that all viruses are malware, but not all malware are viruses, let’s look at some other types of malicious software.
Types of Malware
There is no way to know how much malware is on the Internet, because new ones are always being developed and undiscovered. In the Q2 report for April–June 2015 by PandaLabs (www.pandasecurity.com/mediacenter/reports/), it was stated that during this period they saw “an average of 230,000 new types each day and a total of 21 million new threats during those three months.” A majority of these were variants of existing malware, which are changed to avoid detection.
In addition to new forms of malware being developed, there is polymorphism, in which a virus or other unwanted program is designed to replicate itself with modifications, which makes it harder to detect. Sometimes these variants are identified as new malware, and later recognized as being part of the same family.
Because of the sheer volume of unwanted programs that exist, they’re grouped into different categories so it’s easier to understand their function and characteristics. Some of these categories include:
●Adware is short for advertising-supported software, and is designed to deliver advertisements. You’ve probably experienced pop-up ads on websites or advertisements in free programs (freeware) or those offered on a trial basis (shareware). In these cases, the site or software’s creator gets money through the ads displayed or clicked on, which helps fund his or her endeavors. While this is a legitimate use of adware, it becomes malicious when its bundled with spyware (which we will discuss later) that gathers information about you, and sends it to a third party.
●Backdoors are methods to gain unauthorized access to a system. A software developer may write a backdoor into a program so that he or she can troubleshoot problems, which may also be used by hackers to gain access. Malware may also be used to install a backdoor to a system by taking advantage of some vulnerability in the software. For example, Remote Access Trojans are used to create such backdoors, allowing the attacker access to your system from a remote location. Once in, the attacker has access to your system, and can operate the computer as if he or she was sitting at your keyboard.
●Bots, which are short for robots, are programs that perform a specific task or operate in a way that simulates human activity. They can be used to gather information, deploy additional malware, or used in collections called botnets as part of a larger attack. We will discuss these more thoroughly in Chapter 5, Cybercrime.
●Browser hijackers, which attack Internet browsers, prevent you from navigating to an intended site. This may prevent you from using search engines properly, visiting antivirus sites to get additional help or download removal tools, and may direct you to sites to steal information or download additional malware.
●Exploits are designed to take advantage of system vulnerabilities, such as a security hole in an operating system. It may use a known vulnerability that the vendor has decided to fix later, exists because a patch hasn’t been released yet, or is still a problem on your computer because you haven’t kept your system updated. There are also zero day exploits, which take advantage of vulnerabilities that are unknown to a vendor.
●Password Stealers and Monitoring Tools are used to monitor your system and record information on your activities. They can record passwords as they’re entered, access ones stored in a browser, and (in the case of keyboard loggers) capture anything else you type on a keyboard. We’ll discuss these in greater detail in Chapter 5, Cybercrime.
●Ransomware is a kind of malicious software that prevents access or performs some other action that either locks your computer or devices or encrypts your data, essentially holding your computer/data hostage until you pay the malware’s creator to release it. We’ll discuss this in greater detail in Chapter 4, Email safety and security.
●Rootkits are programs designed to hide on your system and perform specific actions programmed or configured by the attacker. After the rootkit installs, it will reside there until the attacker uses it to gain remote access to your system, install additional malware, or control the computer as part of a botnet. They are difficult to detect, and may need to be removed manually or with special tools available on antivirus and antimalware sites. We will discuss these in detail in Chapter 5, Cybercrime.
●Scareware is a malware that’s designed to scare you into visiting websites that will install other malicious software, or tries to get you to purchase software to remove viruses or other threats that don’t actually exist on your system. We’ll discuss this in greater detail in Chapter 4, Email safety and security.
●Spyware is a software that’s designed to monitor your activities and report them in some way. Spyware may be used to track your browsing activities, log what’s entered on a keyboard, and send this data to a particular email address or server. Tracking cookies may be used to store information about the user on the person’s own computer, and send this information to advertisers or other third parties. In addition to being a threat to your privacy, it may also modify security settings, interfere with network connections, or cause other problems that you may attribute to your operating system or software you’re running. It may be hidden in legitimate software you install, or Trojan Horses that have infected your computer.
●A Trojan Horse (or Trojan) is a malicious software that’s hidden inside or disguises itself as a seemingly harmless program, document, or other file. For example, you might download a flashlight app for your mobile phone. Once installed or executed, it then runs malicious code that harms your system, downloads other malware, or performs some other harmful function. Trojans are the most common form of malware.
●Worms are another common type of malware, and can cause serious problems for computers and networks. They are selfreplicating, and can fill up computer memory and/or consume bandwidth across a network, causing performance issues and errors. They may also include a payload, which is a program that’s released to perform some other action, such as stealing or damaging data, create botnets, and so on.
Read full chapter
URL: //www.sciencedirect.com/science/article/pii/B9780124166509000036
Analyzing the System Hives
Harlan Carvey, in Windows Registry Forensics (Second Edition), 2016
AutoStart
Autostart settings are those that allow applications and programs to start with no interaction from the user beyond booting the system or simply logging in. Registry keys and values within this category are most often associated with malware, as the intention of the authors is to get their malware onto a system and to get it to start automatically when the system is started, with no interaction or notice from the user.
Windows Services
Perhaps the most referenced and analyzed pieces of information in the System hive, particularly during incident response activities, are the Windows services. Windows services are programs that run automatically when the system is booted and are started by the system and with no interaction from the user (however, users with the appropriate privileges can install, start, and stop services). Windows services can be very useful; web and FTP servers, as well as DNS and DHCP servers, are all Windows services. However, the nature of Windows services (run automatically with no user interaction, as well as with elevated privileges) makes them a target for malware authors as well, and a great number of bits of malware install as Windows services.
Services on Windows systems can be extremely powerful; they generally run with elevated privileges and start without any interaction from the user beyond booting the system. Is there any wonder why services are targeted so often by malware authors and intruders? Not so much to exploit a vulnerability (yes, that does happen), but instead to use Windows services as a persistence mechanism, ensuring that the malware or backdoor or remote access Trojan (RAT) is started each time the system is booted.
Warning
Creating services (and other actions, such as submitting Scheduled Tasks) on Windows systems requires Administrator-level privileges; as such, the fact that new services are created tells you something about the level of access that the malware or the intruder had on the system. Analysts often see partial infections by malware, where the infection process was hindered by the fact that user context that was involved did not have Administrator privileges on the system. So while limiting user privileges can prevent or hamper the effects of a compromise, the flip side is that the artifacts of a compromise that you do find can tell you a lot about what may have happened.
In many cases, experienced incident responders will be able to look at a system Registry and “magically” pick out the obscure or malicious services. Some malware creates services with random names (either the service name itself, or the DisplayName value), so a quick look at the Registry is all it takes to find the offending service. Other techniques that can be used by incident responders and analysts are to look for services that have odd paths to the executable images (that is, point to executables in the ProgramData folder, within a user’s profile folder, etc.) or do not have a Description value; many legitimate services have descriptions, and some of them can be long, depending on the vendor. The bad guys learned from these techniques and began using services names that looked a bit more legitimate and began filling in the various values to make the service itself look more legitimate, at least when the values were seen via a Registry viewer. For instance, there have been Description values that appear legitimate, and I have seen others that have had some misspellings (ie, “down load” spelled as two words) which was enough for me to take a closer look.
Another value beneath a service key that can provide a good deal of context and perspective to an examination is the Start value. A description of the various Start values can be found in MS KB article 103000 (found online at //support.microsoft.com/en-us/kb/103000). In most instances, you’d expect a Start value of “0x02”, indicating that the service is autoloaded or run automatically. Every now and again, I see malware services that have a Start value of 0x03, which indicates that they’re set to start manually, meaning that a user must do something, take some action, for the service to be started. This can be critical when attempting to determine the “window of compromise” for a customer. Basically, if the malware service was installed with a Start value of 0x03, started and run, and then the system shut down, when the system was started again, the service would not start automatically. This may play a significant role in your examination.
RegRipper includes a number of plugins for extracting service key information from the System hive, and to be honest, because RegRipper is open source, there’s really no limit to how you parse and display the information. Most of the plugins will start off by locating the ControlSet00n marked “Current” in the Select key of the System hive; however, this is not a hard-and-fast requirement. Plugins can be written that will display the same key/value information from all of the available ControlSets, or you can write a plugin to display the information from both ControlSets if the information itself is not the same in both (or all…I’ve seen hives with more than two ControlSets) locations.
Warning
I was performing emergency incident response for an organization that had some issues with malware. The malware wasn’t widespread and didn’t seem to be infecting systems; in fact, all indications were that the malware was isolated to just a few systems, and the organization simply wanted it gone. Using regedit.exe, I found a service that appeared to be suspicious, deleted it and rebooted the system…but the malware wasn’t gone. In this case, the malware used two services for persistence…one that was the malware, and the other that checked for the existence of the malware, and if it didn’t find it, installed it.
During another incident response engagement, we had located a malicious service that had a Start value of 0x02, and would dump the virtual memory from credit card back office processing software and collect track data from the memory dump. Using some commercial tools, we found that the code within the executable for the service included a sleep() function; it used this because when the system is first started, there is no credit card data in memory. Instead, it would read the contents of a register, shift the value to the right four times, and then sleep() that number of seconds; based on other artifacts, it appeared at one point to sleep() for several days. Under the circumstances, understanding the interaction of the malware on the system, taking all factors into account, helped us provide the customer with a more accurate window of compromise.
In another instance, the first real indicator I’d seen of malicious services was an Event Log record. The source was “Service Control Manager” and the event ID was 7035, indicating that a service had started…even though our findings indicated that the system had been running for quite some time. Further examination indicated that the service was set to start when the system was booted. All other information about the service appeared to be legitimate, even down to the executable file appearing to be a legitimate Windows file.
The point is that it’s not always easy to locate a suspicious service or process, particularly when the bad guy is trying really hard to not be discovered.
Not long ago, the bad guys were found to be employing an even trickier technique to hide and maintain the persistence of their malware or backdoors. Instead of creating a service with an ImagePath value that pointed directly to the malware executable file, what they were doing was creating a service that was loaded by the venerable svchost.exe process. Per MS KB article 314056 (found online at //support.microsoft.com/kb/314056), the Svchost.exe process is essentially a “service host,” in that multiple copies of svchost.exe can be running, each “hosting” multiple services running from DLLs. When the svchost.exe process starts, it reads through the Registry to see which services it needs to be running, under which instances. Services that run under svchost.exe have ImagePath values that contain references to svchost.exe itself, such as:
%SystemRoot%\system32\svchost.exe -k netsvcs
Then, beneath the service key, there will be a “Parameters” subkey that contains a value named “ServiceDll”, which points to the DLL from which the service is run. Conficker is an example of a worm that used this technique for persistence. By creating a service in this manner, it makes the malware a bit harder to find, but not impossible. All we have to do is drop down to the Parameters subkey beneath the malicious service, and the ServiceDll value will point us to the offending malware. Some of the things we’d want to look for with respect to the listed DLL are unusual paths (ie, the path name includes “temp”, etc.), odd looking or apparently names for the DLL itself, etc. Looking at the referenced DLL itself, misspelled or missing file version information, evidence of the use of a packer to obfuscate the executable code, etc., are indicators of possibly malicious files.
Note
The Microsoft\Windows NT\CurrentVersion\SvcHost key within the Software hive can also provide information about services that should be running “under” svchost.exe.
The RegRipper svcdll.pl plugin combs through the services keys within the System hive and displays all of those that are loaded by svchost.exe, sorting them based on their key LastWrite times. The svchost.pl plugin extracts the values and data from the SvcHost key within the Software hive. Because RegRipper and its plugins are open source, anyone with a modicum of Perl programming skill (or even the ability to use copy-paste) can easily create new plugins that perform different functions or display the output in a more meaningful manner. See chapter “RegRipper” of this book for more information regarding writing RegRipper plugins.
A side effect of the use of services as a persistence mechanism for malware is that the Windows XP and 2003 operating systems (similar activity has not been widely observed on Vista systems and above, including Windows 7, etc.) tend to record information that can make an analyst’s task of locating the malware, or the initial date that the system was compromised, a bit easier. In particular, when a service or device driver is actually “run,” in many cases, an entry beneath the System\CurrentControlSet\Enum\Root key appears; specifically, a subkey whose name is “LEGACY_<service name>”, as illustrated in Fig. 3.8.
Figure 3.8. Enum\Root\LEGACY_∗ keys (Windows XP).
Again, these keys appear to be created relatively close to the time that the service is first run. During multiple malware and intrusion examinations involving the creation of services (particularly those that are loaded and run via svchost.exe), there appears to be a correlation between when the file was first created on the system, an Event Log entry indicating that the service was started, and the LastWrite time on the LEGACY_∗ subkey related to the service. This information can be very valuable when attempting to determine and/or validate the time frame of the initial compromise, or an overall window of compromise. In my experience, this information applies primarily to Windows XP and 2003 systems, as I haven’t seen a similar correlation, to a great extent, on Windows 7 systems.
Beneath each of these LEGACY_∗ keys you will often find a subkey named “0000”, which also appears to be created and modified in some way when a service is launched. Therefore, the LastWrite time on the LEGACY_∗\0000 key for a particular service should closely approximate the last time the service was run. For example, on a Windows XP Service Pack 3 system I was examining, the Browser service was configured to start automatically when the system booted. The LastWrite time on the Browser service key was August 11, 2010, at approximately 08:10:28 UTC, and the LastWrite time on the LEGACY_BROWSER\0000 key was 08:11:23 UTC on the same day. As it turned out, the system had last been booted at approximately 08:08 UTC on August 11, 2010. The LastWrite time on the LEGACY_BROWSER key was May 9, 2008 at approximately 01:56:17 UTC, which approximates to the time that the system was installed. This same sort of analysis applies to services that are started manually and should be carefully considered as part of your analysis, including correlating this information with other artifacts from the image, such as Event Log entries, etc.
During an examination I was working on some time ago, I found what turned out to be a service installed within the time frame of an incident. I say “an incident” because, as is sometimes the case, when examining a system to determine the root cause of one incident, I run across indications of a previous or multiple incidents. In some instances, I’ve found indications of multiple different bits of malware, as well as one or more intrusions. In this case, I found a service that had been installed, and the file system metadata (ie, time stamps) for the executable file indicated that it had been created on the system in February 2009, which was 15 months prior to the incident I had been asked to look into. The LastWrite time on both the LEGACY_∗ and LEGACY_∗\0000 subkeys for the service indicated that it had been first launched shortly after the executable file had been created on the system, and that was the only time that the service had been launched. Further analysis determined that the service was not configured to start automatically when the system was booted, but instead was set to be started manually.
Note
The legacy.pl plugin extracts the names of the LEGACY_∗ subkeys from the Enum\Root key and displays them sorted based on their LastWrite times. Correlating this information with the output from other plugins (or any others that extract information about services) can prove to be very beneficial in locating malware, as well as establishing at time frame for the initial intrusion.
Another way that the LastWrite time for the LEGACY_∗ key can be useful in determining the time frame of an incident or intrusion is when the executable file (.exe or .dll file) itself is subject to “time stomping.” That is, there is malware that, when it is installed, the executable file MAC times are modified so that it remains hidden from rudimentary detection techniques, such as searching for new files on a system based on creation dates or creating a timeline of system activity for analysis. In this case, an anomaly may be detected if the creation date for the executable file were sometime in 2004, but the LastWrite time for the service’s LEGACY_∗ key were, say, in 2009.
Warning
Similar to what has been observed with respect to modifying file MAC times (ie, SetFileTime()) to arbitrary times (referred to as “time stomping”), the tool SetRegTime (found online at //code.google.com/p/mft2csv/wiki/SetRegTime) can be used to modify key LastWrite times.
I, and others, have used this technique to great effect. There have been a number of examinations during which I have found a suspicious file, or an unusual service referenced in the Event Log, and locating the LEGACY_∗ entry has led me to other interesting information in my timeline. In most cases, I’ve seen file creations “nearby” in the timeline that provide me with a clear indication of the initial indicators of the incident.
Read full chapter
URL: //www.sciencedirect.com/science/article/pii/B9780128032916000036
Network attacks: Taxonomy, tools and systems
N. Hoque, ... J.K. Kalita, in Journal of Network and Computer Applications, 2014
3.2.1 Trojans
Trojans are malicious executable programs developed to break the security system of a computer or a network. A Trojan resides in a system as a benign program file. Once the user attempts to open the file, the Trojan is executed, and some dangerous action is performed. Victims generally unknowingly download the Trojan from multiple sources such as (i) the Internet, (ii) an FTP archive, (iii) via peer-to-peer file exchange using IRC, and (iv) Internet messaging. Typically, Trojans are of seven distinct types: (a) Remote access Trojans (b) Sending Trojans (c) Destructive Trojans (d) Proxy Trojans (e) FTP Trojans (f) Security software disable Trojans and (g) DoS Trojans.
Remote access Trojans are malware programs that use backdoors to control the target machine with administrative privilege. These type of Trojans are downloaded invisibly with a user request for a program such as a game or an email attachment. Once the attacker compromises a machine, the Trojan uses this machine to compromise more machines to construct a BotNet for launching a DoS or DDoS attack. An example of remote access Trojan is danger. Sending Trojans are used to capture and provide sensitive information such as passwords, credit card information, log files, e-mail addresses, and IM contact lists to the attacker. In order to collect such information, such Trojans attempt to install a keylogger to capture and transmit all recorded keystrokes to the attacker. Examples of this type of Trojans are Badtrans.B email virus, and Eblast. Destructive Trojans are very destructive for a computer and often programmed to delete automatically some essential executable programs such as configuration and dynamic link library (DLL) files. Such Trojans act either (i) as per the instructions of a back-end server, or (ii) based on pre-installed or programmed instructions, to strike on a specific day, at a specific time. Two common examples of this type are Bugbear virus and Goner worm. Proxy Trojans attempt to use a victim's computer as a proxy server. A Trojan of this kind compromises a computer and attempts to perform malicious activities such as fradulent credit card transactions, and launching of malicious attacks against other networks. Examples of proxy Trojans are TrojanProxy:Win32, Paramo.F. FTP Trojans attempt to open port 21 and establish a connection from the victim computer to the attacker using the File Transfer Protocol (FTP). An example of FTP Trojan is FTP99cmp. Security software disable Trojans attempt to destroy or to thwart defense mechanisms or protection programs such as antivirus programs or firewalls. Often such a Trojan is combined with another type of Trojan as a payload. Some examples are trojan.Win32.KillAV.ctp and trojan.Win32.Disable.b. DoS Trojans attempt to flood a network instantly with useless traffic, so that it cannot provide any service. Some examples of this category of Trojan are ping of Death, and teardrop.
Read full article
URL: //www.sciencedirect.com/science/article/pii/S1084804513001756
Strategically-motivated advanced persistent threat: Definition, process, tactics and a disinformation model of counterattack
Atif Ahmad, ... James Boorman, in Computers & Security, 2019
7.5 Assuring sustainability
The sustainment of S-APT operations is to some extent dependent on the maintenance of infrastructure external to the target network. Prior to launching an attack, “command and control” servers—which will be used during the attack to focus efforts, channel traffic and operate malware—must be established and available (Tankard, 2011, 2014; Caglayan et al., 2012). Command and control servers are typically computers that were compromised during previous missions (Bradbury, 2010; Raiu, 2012). Massive offenses have led to the compromise of systems around the globe to create “botnets” that can put tremendous computing power behind S-APT missions (Bradbury, 2010; Sood and Enbody, 2013; Caldwell, 2015). A command and control server may be used to control multiple botnets consisting of numerous compromised systems that are then used to carry out various functions entailed in an S-APT attack, i.e. “one botnet for social engineering (spear phishing), another to infect machines and proxies, and still others to exfiltrate the data” (Caglayan et al., 2012). The command and control server may be in the same country as the target or embedded within infrastructure as a service (IaaS) to make communications with its IP address less conspicuous (Tankard, 2014; Wangen, 2015; Lemay et al., 2018).
Assuring sustainability for an operation is largely a matter of maintaining operator access to the network. In many instances, some assurance of sustainability is accomplished with the initial attack. Penetration via spear phishing, for example, may introduce a malware combination that enables immediate access by exploiting some software vulnerability present in the target system, while also enabling persistent access via the establishment of a clandestine communications channel (Cutler, 2010; Tankard, 2011; Hutchins et al., 2011; Brewer, 2014). This channel, created by a RAT (remote access Trojan—or toolkit) may be designed to install itself onto a host and run as a service (Brewer, 2014; Caldwell, 2015), enabling constant access to the network by the S-APT operator. The RAT is configured to initiate an outbound (“reverse”) connection (Chang et al., 2016) between the victim system and the attacker's command and control server, and typically communicates back to the operator with encrypted traffic sent over port TCP 443 (HTTPS) to the command and control server, to appear as normal outbound web traffic (Brewer, 2014; Moon et al., 2014). The RAT calls back to the operator at designated intervals to indicate that the backdoor remains open and enabling communications between itself and the command and control server to appear as trusted (Smiraus and Jasek, 2011; Steer, 2014).
Researchers from ESET report a technique that is particularly difficult to detect and which is thought to have been used by APT28 to assure sustainability. This involved using an UEFI root kit dubbed Lojax to attack misconfigured or vulnerable computers to obtain persistence that is resistant to replacement of storage devices or reinstallation of operating systems (ESET, 2018). ESET report that the Lojax root kit is installed by a combination of custom and freely available tools which are most likely delivered to the target system by an initial infiltration technique (ESET, 2018). The root kit writes and installs a maliciously modified version of the small agent component for Lojack anti-theft software to the infected computer's storage device each time the system firmware selects the boot device at startup, while the operating system is loading, thus ensuring persistence (ESET, 2018). Lojax small agent acts as a service and is thought to be able to connect to command and control servers to download additional tools as required (ESET, 2018). ESET propose that the attack may go undetected because the legitimate Lojack software is often whitelisted by antivirus software, making it more difficult to detect the modified Lojax small agent (ESET, 2018). ESET note from their investigation that the use of the Lojax UEFI root kit was rare and used to target “mostly government entities located in the Balkans as well as Central and Eastern Europe” (EST, 2018).
As a single back door would constitute a single point of failure for the whole operation, S-APT operators generally take additional steps to ensure persistent and redundant access, i.e. via implantation of multiple backdoors/remote access tools (Smiraus and Jasek, 2011; Tankard, 2011; Brewer, 2014; Caldwell, 2015), or by securing multiple user credentials (SBIC, 2011; Krombholz et al., 2015). This redundant accessibility naturally supports continued access even if one or more backdoors or compromised accounts are discovered and eliminated (Brewer, 2014; Caldwell, 2015).
Credential theft is the most common way to maintain access to a network (Brewer, 2014), and a higher level of assurance can be afforded through the theft of multiple user credentials (Krombholz et al., 2015). Malware is sometimes programmed to automatically “harvest” credentials and escalate privileges on them to gain administrative rights (Thomson, 2011; Chang et al., 2016). Credential theft helps to assure redundant access after the initial compromise (Smith, 2013; Brewer, 2014). Often a lower-privileged user's credentials are the first to be stolen and privileges are then escalated by stealing additional, higher-privileged credentials once access has been gained (Caldwell, 2015), or by exploiting software vulnerabilities to assign higher privileges to credentials already in possession (Chang et al., 2016).
Stolen credentials that enable the S-APT operator to simply log on and navigate the network unnoticed may be all that is required to achieve mission objectives (Smith, 2013). If sufficient privileges can be obtained by the S-APT operator (e.g. captured through manual or automated information gathering), the use of malware may no longer be necessary (Brewer, 2014; Caldwell, 2015). In some cases, the attacker may create a new user account separate from the organization's extant accounts (Caldwell, 2015), though this risks detection where accounts are monitored for such changes.
A “configuration mistake” (Bing, 2018) written into Triton/Trisis led to application code failing a validation check between redundant processing units, which in turn initiated a safe shutdown mode by the safety instrumented system controller (Hand, 2017). This event led to a forensic investigation which uncovered an executable file (“trilog.exe”)—disguised to look as though it came from Schneider Electric but, upon inspection, created by someone outside of the company—with an attached zip file (“Library.zip”) found to contain Triton/Trisis, effectively terminating the S-APT operation (Bing, 2018). If the configuration mistake had not been made, no anomaly would have been detected, the shutdown would not have occurred, a forensic investigation would not have been launched, and the operation might have been sustained “for years” (Kling, in Hand, 2017).
Read full article
URL: //www.sciencedirect.com/science/article/pii/S0167404818310988
Ransomware threat success factors, taxonomy, and countermeasures: A survey and research directions
Bander Ali Saleh Al-rimy, ... Syed Zainudeen Mohd Shaid, in Computers & Security, 2018
4.2.3 Ransomware prediction
Early detection, also called early prediction (Das et al., 2016a), focuses only on data that are extracted at the early stages of the malware's execution (Al-rimy et al., 2018). The common limitation of traditional detection techniques is the inability to deal with the irreversible nature of ransomware attacks (Mohurle and Patil, 2017). That is, these techniques depend on data extracted during the actual ransomware attack (Abaid et al., 2016). As such, the detection takes place after the fact, i.e. after the encryption happens. This type of detection is not suitable for ransomware (Sgandurra et al., 2016). To efficiently detect ransomware, what really needed is early prediction, which enables taking preventive actions on time. Das et al. (2016a) proposed an online malware detection model with the capability of early prediction. However, the early prediction accuracy was relatively low. One reason is that the detection model was built based on the entire feature space extracted from the whole trace file collected during the execution of the malware instance. The model was then used to predict malware using a fraction of the feature space taken from early phases of instance execution process, i.e. during first 10, 20, 30% …. etc. of the execution time. Additionally, Jiang and Omote (2015) built an early detection model upon the assumption that the time interval of the early stages of communication of the Remote Access Trojan (RAT) is normally shorter than that of benign programs. With the use of Random Forest (RF), the study achieved around 96% accuracy rate. However, false positives were around 20%, which is relatively high.
Several studies have proposed early prediction solutions such that the ransomware could be identified before it carries out the encryption or contained before it causes any major damage. By focusing on user files, Kharraz et al. (2016); Scaife et al. (2016) were able to discover the changes happening to these files and inform the user about them before more files were attacked. In their study, Kharraz et al. (2016) employed the measurement of entropy to build the UNVEIL system that examines the entropy difference between input and output buffers. The system is activated whenever user files get accessed. If the difference is high, it is evidence that the file has been encrypted. Using this strategy, ransomware could be detected and stopped at early stages of the attack and before it inflicts major damage. However, the proposed technique sacrifices encrypting some files before detection takes place. These files could be more important for the user than others. Thus, in using this technique users are not fully protected. Similarly, Scaife et al. (2016) correlated entropy with other factors, including file funneling and deletion, to detect the changes that user-related files have undergone after they have been accessed. This technique treats high entropy values as evidence of encryption activity carried out by ransomware. Like the technique proposed in Kharraz et al. (2016), the study sacrifices part of the user data before detection happens.
In the study conducted by Sgandurra et al. (2016), authors propose the idea of taking and utilizing the onset of crypto-ransomware runtime data for building an early detection model. The model was built based on temporal thresholding by executing the ransomware instances for a pre-defined time and using the collected data to build the detection model. Although this idea is suitable for ransomware early detection, authors extracted these data based on a fixed time for all instances. In addition, such an approach lacks clarity in defining the pre-encryption phase, which is not the same among all ransomware instances. To fill this gap, Al-rimy et al. (2018) put forward a framework that defines the pre-encryption phase among ransomware families and utilizes the data extracted during that phase to build an early detection model. The study focuses on drawing a clear boundary between pre-encryption, during-encryption and post-encryption phases, which varies between different ransomware instances and families. However, the study presented the idea theoretically and did not provide implementation details.
The existing software tools for ransomware analysis, detection and prediction are summarized in Table 3. It shows that Cuckoo sandbox is the preferred tool for dynamic analysis in several studies. Additionally, in the data-centric studies, entropy and similarity-based measurements are utilized to compare the file before and after it gets accessed. The increase in the file entropy or the low degree of similarity before and after the file access could indicate cryptography. Moreover, and like malware studies, ransomware detection and prediction studies utilize Natural Language Processing (NLP) techniques such as Term Frequency Inverse Document Frequency (TF-IDF) and N-gram to extract the features that are used to train machine learning and statistical-based detection/prediction models.
Table 3. Tools for ransomware analysis, detection, and prediction.
| Analysis | Dynamic Analysis | Cuckoo Sandbox | Kharraz et al. (2016); Scaife et al. (2016); Sgandurra et al. (2016); Al-rimy et al. (2017); |
| Microsoft Filesystem Minifilter Driver | Kharraz et al. (2016) | ||
| File Screening service | Moore (2016) | ||
| Static Analysis | ApkTool | Andronio et al. (2015); Maiorca et al. (2017). | |
| Detection/Prediction | Features Extraction and Factorization | Term Frequency (TF), Term Frequency-Inverse Document Frequency (TF-IDF), Frequency-Centric Model (FCM), Natural Language Processing (NLP), N-gram | Andronio et al. (2015); Mbol et al. (2016); Maiorca et al. (2017); Al-rimy et al. (2017) |
| Features Selection | Mutual Information (MI), Information Gain (IG) | Sgandurra et al. (2016); (Al-rimy et al. (2017) | |
| Classification | Support Vector Machine (SVM), Logistic Regression, Random Forest, Baysian Belief Network, Naïve Bayes | Ahmadian and Shahriari (2016); Sgandurra et al. (2016) Maiorca et al. (2017); Al-rimy et al. (2017) | |
| Similarity Measurement | Structural similarity (SSIM), Cosine similarity | Andronio et al. (2015); Kharraz et al. (2016) | |
| Entropy Measurement | Shannon Entropy, Relative Entropy (also called Kullback–Leibler divergence) | Scaife et al. (2016); Mbol et al. (2016); Kharraz et al. (2016) |
Read full article
URL: //www.sciencedirect.com/science/article/pii/S016740481830004X