DNS Concepts 1
If the IP address is an IPv4 address, then this is an A query.
DNS Concepts 2
For a PTR record lookup of 8.8.4.4, the hostname used in the query would be:
4.4.8.8.in-addr.arpa.
DNS Concepts 3
That’s an SRV record (Service Record) query where _sip is the symbolic name of the service, tcp is the name of the transport protocol and mycompany.com is the domain name.
DNS Concepts 4
We can use the below command:
we find the below answers:
DNS Concepts 5
To find SPF records for admin@mail.sec450.com, I need to query the TXT records for the domain part of the email address (mail.sec450.com):
DNS Logs 1
We can filter the Bro-DNS dashboard for A record request only:
DNS Logs 2
Using the sam dashboard as above, we can easily find the client within the SEC450 domain that was the source of the highest count of DNS request:
DNS Logs 3
We filter out DNS query types that are not A or CNAME queries and we also filter out the DC IP address:
We find the following list of external DNS servers that were queried:
DNS Logs 4
IDN domains use Punycode encoding – they start with xn-- when encoded. Filtering for queries starting with xn--, we find the following query:
HTTP Interpretation 1
The response code from the server is 200 OK which is a successful request.
HTTP Interpretation 2
The answer can be found in the User-Agent section of the Request.
The User-Agent string shows “Firefox/101.0” which indicates Firefox version 101.0. The rest of the string provides additional system information – it’s running on Windows NT 10.0 (Windows 10) on a 64-bit architecture, with the Gecko rendering engine version 67.0.
HTTP Interpretation 3
The server section displays the webserver software that is used to provide the response and the version number:
The software and the version number are not shared and it is not a common thing. It usually says something like Apache or nginx and a version number.
HTTP Logs 1.1
Using the Bro-HTTP dashboard in Opensearch, we can quickly filter for all the source IP addresses in the sec450.com domain. We can then look for the common User-Agent used by these addresses:
HTTP Logs 1.2
The CIDR for the DMZ subnet is 10.0.3.0/24
I can search for it in the Bro-HTTP dashboard:
I can then filter for it in the Destination IP address part of this address:
We can filter for POST requests only:
We then the result we were looking for:
HTTP Logs 1.3
Web scanning often creates a high volume of requests.
The IP address doing the scanning is 192.165.1.156 and it is using a tool called Nikto which is a popular open-source tool used for web server scanning to identify potential security vulnerabilities, misconfigurations, and dangerous files/programs.
HTTP Logs 1.4
OpenSearch has a NIDS dashboard that may be useful. We can filter for the source IP address that was scanning the DMZ server in the last question:
We see that there are 86,312 alerts tied to this address.
The name of the most common alert is:
HTTP Logs 1.5
A brute force attack typically involves automated attempts to guess credentials by systematically trying different username/password combinations. We expect to see hundreds or thousands of requests to login endpoints in a short timeframe, requests coming from the same IP address (or a few IPs), different username/password combinations being attempted and a high frequency of HTTP 401/403 responses (authentication failures).
The primary HTTP method used for login attempt is the POST method.
Based on these general observations, we are going to use our Bro-HTTP dashboard and filter for POST request that generated an “Unauthorized” status message:
The source IP address generating these messages is:
HTTP Logs 1.6
This IP address never generated an “Authorized” status message from the webserver so we can safely assume that he never guesses his way into the site:
HTTP Phishing 1
Using the Visualization Tab and using the NIDS-Alert Summary visualization , we quickly find the below alert:
HTTP Phishing 2
To find the hostname, I used a DHCP visualization where I was able to map the source IP to a hostname (LPT05)
To map this hostname to a username, I used the Sysmon-logs dashboard, where I sorted by hostname and looked for the most frequent username associated with the hostname (link):
HTTP Phishing 3
We can use the Bro-HTTP dashboard and filter for POST method that resulted in a successful connexion:
There is only one connexion associated with this filter, and we can easily retrieve the domain name and URI for it in the dashboard:
HTTP Phishing 4
Using Wireshark, we can filter for the POST request:
Looking in the HTML section of this packet, we can find the username and password used to authenticate:
HTTP Phishing 5
Looking at the first GET request of this HTTP session, we find the lookalike domain that led to the phishing site:
HTTP Phishing 6
Based on the question, I am looking for DNS queries that occur between the initial page load (ducussign.com) and the POST submission. More specifically I am looking for common redirect services: bit.ly, tinyurl.com, rebrandly.com, goo.gl, t.co, ow.ly, etc.
In Wireshark, I used a filter for DNS A records and PTR records that might reveal service domains. I looked specifically at the packets between the initial page load and the POST request:
I find a DNS request for bit.ly pretty quickly.
HTTP Phishing 7
I used a filter in Wireshark that searches through HTTP traffic for specific text (bit.ly):
Looking at the packet content, I quickly find the link:
HTTP Phishing 8
We already know that the IP address for the phishing site is 199.192.19.138. We use it as filter in NIDS dashboard:
3 IDS alerts are associated with this address:
Looking at the logs, we can find the SID for each one of these alerts:
TLS 1.3
I used the SSL dashboard to solve this question and use the TLSv1.3 filter:
Looking at the logs, the organization these SSL connections are all associated with is google:
Let’s Encrypt!
We used the X.509 – Certificate Subject dashboard and filtered for the Let’s Encrypt service.
We see six unique domain names that were visited from the sec450.com network:
IDS meets encryption
We are looking for encrypted traffic to a web-based service therefore it makes sense to filter our NIDS dashboard using port 443:
There are only 3 total alerts generated using this filter and there are all under the same alert name:
How much data?
Using the Bro-Connections dashboard, we filter it using the source ip address found in the last question:
We see 4 connections and looking at the detailed logs for each one of them we can find the total number of bytes that was transferred:
We find a total of 28KB which is not number that would be pointing to the exfiltration of a large DB.
Email Analysis 1.1
Looking at the content of this email:
We find that the email Title is:
Email Analysis 1.2
To find this IP address, we have to look at the headers and remember they are listed in reverse chronological order from newest to oldest. We see that the address that passed this email to the gmail infrastructure is:
Email Analysis 1.3
I mentioned in the last question that email headers are in reverse chronological order, therefore the solution to this question is located with the first items at the bottom of these “Received: From” headers.
Email Analysis 1.4
We can easily find this information in the “From” header:
Email Analysis 1.5
To answer this question, we have to look for the Return-Path header:
Email Analysis 1.6
Looking at the headers, we can see that both SPF and DKIM passed but there is no line explicitly showing that the DMARC check passed:
Email Analysis 1.7
Nothing appear to be malicious with this email from what we have seen so far with our analysis from question 1 to 7.
Email Analysis 2.1
We are moving on to analyse a different email:
Email Analysis 2.2
Email Analysis 2.3
Email Analysis 2.4
The SPF check failed:
Both the DKIM and the DMARC checks are not shown in the headers.
Email Analysis 2.5
The SPF checks failed therefore this email does appear to have been spoofed. The domain of info@mail.com does not designate the ip address 170.210.54.131 as a permitted therefore we can safely assign that this email address was spoofed.
Email Analysis 2.6
Starting from the bottom of the headers, we find 3 hostname with DNS entries that the email has passed through:
Email Analysis 2.7
Similar to the last question, we start at the bottom and write down all the IP addresses the mail passed through ignoring the X-received line:
10.7.155.185, 129.205.112.156, 172.20.4.2, 170.210.54.131, 2002:a6b:5a15:0:0:0:0:0
Email Analysis 2.8
I went to VirusTotal to solve this question. The country is Nigeria.
Rogue Device
Which logs would report the hostnames seen on the network? I used the DHCP dashboard as this would definitely reports all the hostnames and associated IP addresses seen on the network. I then did a long-tail analysis of all these hostnames and one of them stood out as it only had two log counts which was odd and worth investigating:
Looking at the DHCP process for this address, we can see that it looks very odd compared to how the other addresses on the network interacted with the DHCP server.
We see two connections made to the server over a 2 minutes span:
The second one is the odd one, as the Offer and the Ack steps are usually steps emanating from the DHCP server itself and not from a system trying to get an IP address assigned. Looking at the logs, we find this system hostname and IP address:
SSH Outbound
Looking at the SSH dashboard, we quickly find an SSH connection made to port 2222:
Filtering for this one connection, we quickly find the source and destination IP addresses:
An Attempt Was Made…
We know that the rogue device IP address is 10.0.2.18. Looking at our Connections dashboard, we are going to filter for this specific address. We then filter the dashboard for connection made to port 445. We see a total of 8 connections all made to the same destination IP address over port 445:
This dashboard does not indicate the hostname or the username used to connect though. We see that the NTLM was the authentication protocol that was used therefore it’s probably a good idea to look at the NTLM dashboard hoping to find more info there. We quickly find the username in these NTLM logs:
Looking at the NTLM logs we can also find the name of the asset they tried to connect to:
Remote Administration
I first looked at the RDP dashboard but there was no connection logged. I then looked at the Connection dashboard for connection to port 5985 (WinRM over Http) and I found 6 connections:
These connections are all between the same two IP addresses:
A Virus You Say?
We know that the event number in Windows Defender corresponding to a malware being detected is 1116. Using the Beats dashboard and filtering by this Event ID # we find the host name as well as the threat name:
USB Device
The windows event 6416 is a USB plug and play event. It gets triggered every time a play and play device is inserted into the system. Still using the Beats dashboard and filtering by this event number we can see that this event was triggered 51 times.
We see 6 different machines had plug and play device inserted into them.
We are looking for the insertion of a mass storage device. Each log gives the specific description and ID of the device that was inserted. We find our culprit in the second log:
File Sharing is Caring
Still using the Beats Dashboard, we filter for Event ID 4624 (successful logins) to the file share SRV02. There are 159 successful connections to this file share:
Looking at the logs, we find 3 usernames connected to these connections:
Mario, Dkong and Kirby.
Let Me In!
What Is It?
Looking at the USB Drive question log ,we find the following line with the Vendor ID and Product ID for this USB device:
Searching for this VID and PID on the internet, we find that it is a flash drive made by silicon motion.
Love Letter 1
First, we generate the MD5 hash:
We then enter this file hash in VirusTotal and we look for the name given to it by Symantec:
Love Letter 2
We are looking for an executable file therefore we can assume that the string .exe will show up somewhere in our text file. We use the below command to find it:
We quickly find the URL using this technique.
Love Letter 3
Looking at the malware code, I can identify the non-HTTP protocol by examining the infectfiles() subroutine.
The code specifically checks for mIRC-related files:
When it finds these files, it creates a script.ini file that automatically executes IRC commands:
This script automatically sends the malicious file to anyone who joins an IRC channel where the infected user is present.
mIRC is an Internet Relay Chat client, and IRC has historically been a popular protocol for botnet command and control because it allows real-time communication with multiple infected machines through chat channels.
Love Letter 4
Secure Document 1
We use the strings command to scrape out the url without actually opening the file and we grep for http to quickly find it.
Secure Document 2
We can use a simple command to find the metadata for this file:
Secure Document 3
The data was already contained in our previous answer:
Secure Document 4
Using the website viewdns.info/iphistory, I entered the domain name globalsmedical.com and searched for the IP address that this domain was pointing to at the time the document claimed to be made (January 26th, 2017):
Leave a Reply