- August 10, 2021
- Posted by: team SOUTECH
- Category: Blog, Blogging, CEH, CISCO, CISSP, Cyber-security and Ethical Hacking Training, cyberOps, Ethical Hacking and Kali Linux Free Training, Intelligence, Security, Softwares, Wireshark
In this lab you will:
Part 1: Investigate the Attack with Sguil
Part 2: Use Kibana to Investigate Alerts
This lab is based on an exercise from the website malware-traffic-analysis.net which is an excellent resource for learning how to analyze network and host attacks. Thanks to [email protected] for permission to use materials from his site.
Note: This lab requires a host computer that can access the internet.
Background / Scenario
In March 2019, network security monitoring tools alerted that a Windows computer on the network was infected with malware. In this task, you are to investigate the alerts and answer the following questions:
- What was the specific time of the attack on 2019-03-19?
- Which Windows host computer was infected? Who was the user?
- What was the computer infected with?
- Security Onion virtual machine
- Internet access
Part 1: Investigate the Attack with Sguil
In Part 1, you will use Sguil to check the IDS alerts and gather more information about the series of events related to an attack on 3-19-2019.
Note: The alert IDs used in this lab are for example only. The alert IDs on your VM may be different.
Step 1: Open Sguil and locate the alerts on 3-19-2019.
- Login to Security Onion VM with the analyst username and cyberops
- Launch Sguil from the desktop. Login with username analyst and password cyberops. Click Select All and Start Sguil to view all the alerts generated by the network sensors.
- Locate the group of alerts from 19 March 2019.
According to Sguil, what are the timestamps for the first and last of the alerts that occurred on 3-19-2019? What is interesting about the timestamps of all the alerts on 3-19-2019?
01:45:03 to 04:54:34. The alerts show suspicious activity for a little over 3 hours but the majority of the alerts took place for a little over 3 minutes and 43 seconds.
Step 2: Review the alerts in detail.
- In Sguil, click the first of the alerts on 3-19-2019 (Alert ID 5.439). Make sure to check the Show Packet Data and Show Rule checkboxes to examine the packet header information and the IDS signature rule related to the alert. Right on the Alert ID and pivot to Wireshark. Based on the information derived from this initial alert answer the following questions:
What was the source IP address and port number and destination IP address and port number?
Source: 10.0.90.215:52609, Destination: 10.0.90.9:53
What type of protocol and request or response was involved?
UDP, Dynamic DNS, update and response
What is the IDS alert and message?
Alert udp $EXTERNAL_NET any -> $HOME_NET 53, msg: “ET POLICY DNS Update from External net
Do you think this alert was the result of an IDS misconfiguration or a legitimate suspicious communication?
This alert may be the result of a misconfiguration in the IDS because the DNS request was a Dynamic DNS update from an internal host to a DNS server on the internal network and not from an external network to the internal network.
What is the hostname, domain name, and IP address of the source host in the DNS update?
Bobby-Tiger-PC, littletigers.info, 10.0.90.215
- In Sguil, select the second of the alerts on 3-19-2019. Right click the Alert ID 5.440 and select Transcript.
From the transcript answer the following questions:
What is the source and destination IP address and port numbers?
Source 10.0.90.215:49204 and Destination 220.127.116.11:80
Looking at the request (blue) what was the request for?
Looking at the reply (red) many files will reveal their file signature in the initial few characters of the file when viewed as text. File signatures help identify the type of file that is represented. Use a web browser to search for a list of common file signatures.
What is the initial few characters of the file file. Search for this file signature to find out what type of file was downloaded in the data?
The initial characters of this fiel is MZ, a Windows executable .exe or .dll file
- Close the transcript. Use Wireshark to export the executable file for malware analysis (File > Export Objects > HTTP…). Save the file to the analyst’s home folder.
- Open a terminal in Security Onion VM and create a SHA256 hash from the exported file. Use the following command:
[email protected]:~$ sha256sum test1.exe
- Copy the file hash and submit it to the Cisco Talos file reputation center at https://talosintelligence.com/talos_file_reputation.
Did Talos recognize the file hash and identify it as malware? If so, what kind of malware?
Yes, win32 trojan-spy-agent
- In Sguil select the alert with Alert ID 480 and the Event Message Remcos RAT Checkin 23. Notice that the IDS signature has detected the Remcos RAT based on the binary hex codes at the beginning of communication.
- Right click the Alert ID and select Transcript. Scroll through the transcript and answer the following questions:
What is the destination port of the communication? Is it a well-known port?
The destination port is 2404 and it is not a well-known port.
Is the communication readable or is it encrypted?
It is encrypted
Do some online research on Remcos RAT Checkin 23. What does Remcos stand for?
Remote control and surveillance software
What type of communication do you think was being transmitted?
A keylogger possibly sending keystroke information to a C2C server
What type of encryption and obfuscation was used to bypass detection?
Remcos RAT uses multiple packers, base64 encoding and RC4 encryption to bypass detection and throw off security analysts
- Using Sguil and the remaining alerts from 3-19-2019, locate the second executable file that was downloaded and check to see if it is known malware.
What Alert IDs alert to a second executable file being downloaded?
Answers may vary. In this example, 5.483, 5.485, 5.497, 5.509, 5.521, 5.533
From which server IP address and port number was the file downloaded from?
What is the name of the file that was downloaded?
Create a SHA256 hash of the file and submit the hash online at Cisco Talos File Reputation Center to see if it matches known malware. Is the executable file known malware and if so, what type? What is the AMP DETECTION NAME?
Yes, PE32 executable, trojan downloader Win.Dropper.Cridex::1201
- Examine the remaining three alerts from 3-19-2019 by looking at the header information in Show Packet Data, the IDS signature in Show Rule, and the Alert ID Transcripts.
How are all three alerts related?
All three alerts are encrypted and all three alerts were triggered by a blacklisted malicious SSL certificate – Dridex
- Even though you have examined all the alerts in Sguil related to an attack on a Windows host on 3-19-2019, there may be additional related information available in Kibana. Close Sguil and launch Kibana from the desktop.
Part 2: Use Kibana to Investigate Alerts
In Part 2, use Kibana to further investigate the attack on 3-19-2019.
Step 1: Open Kibana and narrow the timeframe.
- Login to Kibana with the analyst username and cyberops
- Open Kibana (username analyst and password cyberops), click Last 24 Hours and the Absolute time range tab to change the time range to March 1, 2019 to March 31, 2019.
- The Total Log Count Over Time timeline will show an event on March 19. Click that event to narrow the focus to the specific time range of the attack.
Step 2: Review the alerts in the narrowed timeframe.
- In the Kibana dashboard scroll down to the All Sensors – Log Type Review both pages and note the variety of log types related to this attack.
- Scroll down and notice that the NIDS Alert Summary in Kibana has many of the same IDS alerts as listed in Sguil. Click the magnifier to filter on the second alert ET TROJAN ABUSE.CH SSL Blacklist Malicious SSL certificate detected (Dridex) from Source IP Address 18.104.22.168.
- Scroll down to All Logs and click the arrow to expand the first log in the list with source IP address 22.214.171.124.
What is the geo country and city location for this alert?
United Kingdom, Newcastle upon Tyne
What is the geo country and city for the alert from 126.96.36.199?
- Scroll back to the top of the page and click the Home link under Navigation.
- Earlier we noted log types like bro_http listed in the Home dashboard. You can filter for the various log type but the built-in dashboards will probably have more information. Scroll back to the top of the page and click HTTP in dashboard link under Zeek Hunting in Navigation.
- Scroll through the HTTP dashboard taking notice of the information presented and answer the following questions:
What is the Log Count in the HTTP dashboard? From what countries?
4, United States and Netherlands
What are the URIs for the files that were downloaded?
/f4.exe, /ncsi.txt, /pki/crl/products/CSPCA.crl, and /test1.exe
- Match the HTTP – URIs to the HTTP – Sites on the dashboard.
What are the CSPCA.crl and ncsi.txt files related to? Use a web browser and a search engine for additional information.
CSPCA.crl is a request for the Microsoft certificate revocation list and ncsi.txt refers to network connection status indicator and is used automatically by windows hosts as a self-test to verify online connectivity.
Reference links for more information:
- Scroll back to the top of the web page and under Navigation – Zeek Hunting click DNS. Scroll to the DNS Queries visualization. Notice page 1 and page 3 of the DNS queries.
Do any of the domains seem potentially unsafe? Try submitting the URL toptoptop1.online to virustotal.com. What is the result?
4 detection engines recognize the URL as malicious regarding malware
- For further investigation and curiosity, try examining the following Zeek Hunting dashboards:
DCE/RPC – for information about the Windows network remote procedures and resources involved
Kerberos – for information on the hostnames, and domain names that were used
PE – for information on the portable executables
SSL and x.509 – for information on the security certificate names and countries that were used
SMB – for more information on the SMB shares on the littletigers network
Weird – for protocol and service anomalies and malformed communications