Scenerio:

One of the employees has received a suspicious document attached in the email. When the e-mail flow is examined, it is seen that there is a suspicious Office file. Employees forward the email to the security team for analysis.

When L1 analysts scan the suspicious file with several different scanning tools, they see that it does not contain VBA macros. Since the file format is similar to phishing, they forwarded the suspicious Office file to you for detailed analysis.

Analysis:

Utilizing Oletools I determined the attackers used a function to make the malicious VBA macros they have prepared run when the document is opened. The attackers change the cell name to ‘auto_open’ to make Excel 4.0 macros work to provide the same functionality (Figure 1).

Figure 1 Deobfuscated excel file

The address of the first cell where Excel 4.0 macros will run in the malicious Office document is ‘Doc4!BA7’ (Figure 1).

Figure 2 Screenshot of Excel 4.0 macro file opened in LibreOffice Calc

The function ‘exec’ is used to start a process in the operating system in the document (Figure 3).

Figure 3 Embedded Excel 4.0 macros

The “Living off the Land Binaries and Scripts” (LOLBAS) tool used in the Excel 4.0 macros was Regsvr32.exe (Figure 3).

The excel file is uploaded to Virus Total and it is determined to be malicious. Figure 4 Virus Total Analysis

Figure 5 Malicious excel file’s IOCs

Regsvr32.exe registers and unregisters DLL and ActiveX controls in Windows Registry. In this excel file, Regsvr.exe registered and executed ‘iroto.dll’, a malicious DLL file (Figure 6). Iroto.dll is capable of loading and rewriting excutables, to execute hidden code.

Figure 6 Screenshot from Virus Total of terminated processes

Utilizing labs.inquest.net, I was able to determine the file was last modified by the username Amanda (Figure 7).

Figure 7 Screenshot from Inquest labs of the excel files metadata

The pcap file ‘webserver.em0.pcap’ was opened in Wireshark. The ‘http’ filter was used to filter through the logs for all http packets. There were a total of 5 HTTP GET requests (Figure 2).

Figure 2 Filtered ‘http’ results from the pcap file

The User-agent string was Lynx/2.8.7rel.1 libwww-FM/2.14 SSL-MM/1.4.1 OpenSSL/0.9.8n. The version of OpenSSL running is OpenSSL/0.9.8n. The name and version of the server it was sent from is Apache/2.2.15. The server operating system is FreeBSD (Figure 3).

Figure 3 TCP stream of packet with response code 200

By following the TCP stream of a packet with the response code 200 (Figure 3), I was able to determine the username and password used for user authenticaiton. The string ‘d2ViYWRtaW46VzNiNERtMw4=’ was decoded from Base64, providing the username and password (Figure 4).

Figure 4 Decoded user authentication username and password

Figure 1 Overview of email

In the source file of case2.eml, the authentication results showed that the SPF result was ‘SoftFail.’ A SoftFail indicates that the sending activity is flagged as suspicious but still accepted, which often leads to the email being marked as spam. The smtp.mailfrom is designated as letsdefend.io, a valid domain. The DKIM (DomainKeys Identified Mail) status is ‘none,’ meaning the DKIM signature is absent. The DKIM signature is crucial for email authentication, as it allows the receiver to verify that the email originated from the specified domain and was authorized by the domain owner(Figure 2).

The DMARC check failed, but since the policy action was set to “none,” the email was still delivered to the recipient. DMARC (Domain-based Message Authentication, Reporting, and Conformance) works in conjunction with SPF and DKIM to allow domain owners to specify how to handle emails that fail authentication checks. When a DMARC check fails, it typically means that the email did not pass either the SPF or DKIM checks. The “none” policy setting enables domain owners to monitor email traffic without affecting delivery, providing valuable insights for improving email authentication (Figure 2).

Figure 2 Source file of email case2.eml

The domain ‘emkei.cz’ initiated server communication at 17:46:08 with the server AM2PEPF0001C70A.mail.protection.outlook.com via Frontend Transport. The IP address associated with ‘emkei.cz’ is 114.29.236.247. As shown in Figure 2, the ‘Received-SPF’ header specifies a ‘SoftFail’ occurred, indicating that “the domain of transitioning letsdefend.io discourages the use of 114.29.236.247 as a permitted sender.” Further analysis of the domain ‘emkei.cz’ reports it as untrusted (Figure 3). Despite the ‘SoftFail’, the email was allowed to be transmitted.

Figure 3 Domain reputation of emkei.cz via Cisco Talos Intelligence Search

Conclusion

In summary, the combination of suspicious sending and ‘reply-to’ addresses, the ‘SoftFail’ in SPF, absence of DKIM, and a failed DMARC check, alongside the use of an untrusted domain, all point to the likelihood of this email being part of a phishing attempt. This case underscores the importance of robust email authentication and monitoring mechanisms to protect against phishing and other email-based threats.

Background:

One of the employees has received a suspicious document attached in the invoice email. They sent you the file to investigate. You managed to extract some strings from the VBA Macro document. Can you refer to CyberChef and decode the suspicious strings?

Analysis

To begin the analysis, the suspicous document ‘invoice.vb’ was opened in the Linux terminal. The bash command ‘strings’ was used to extract readable text from the file.

Figure 2 Output in the Linux terminal from the ‘strings’ bash command

The first string which is underlined in red, in figure 3, was input into Cyberchef using the ‘from Charcode’ recipe. The output of the string is tinyurl.com/g2z2gh6f. The document initiates the download of a payload after execution which is hosted on tinyurl.com/g2z2gh6f (figure 4).

Figure 3 First string output from the bash command ‘strings’.

Figure 4 Decoded string from the suspicious file using CyberChef

The filename of the payload was discovered by decoding next string from document in CyberChef. The output was ‘dropped.exe’.

Figure 5 Decoded string from the suspicious file using CyberChef

The suspicious document is using method ‘MSXML2.ServerXMLHTTP’ to establish an HTTP connection between files on the malicious web server (figure 6).

Figure 6 Decoded string from the suspicious file using CyberChef

The malicious web server is using the user-agent, Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0), (figure 7).

Figure 7 Decoded string from the suspicious file using CyberChef

The attacker uses the object ‘ADODB.Stream’ to read and write text and binary files (figure 8).

Figure 8 Decoded string from the suspicious file using CyberChef

The attacker uses the object ‘winmgmts:\.\root\cimv2:Win32_Process’ for WMI execution (figure 9). This allows the attacker to gather system information, execute commands or scripts on remote systems and automate routine task or deploy software.

Figure 9 Decoded string from the suspicious file using CyberChef

Technologies and Tools used: Linux terminal, Bash, CyberChef

This challenge is hosted via Letsdefend.io: https://app.letsdefend.io/challenge/Malicious-VBA

A malicious download was attempted from NicolasPRD but the action was blocked. The user NicolasPRD had not logged in since Mar, 07, 2021, 04:30 PM (figure 2). This security event occurred Mar, 14, 2021, 07:15 PM (figure 1).

Figure 1 Details of the alert

Figure 2 Endpoint information on the host

I uploaded the document into Hybrid analysis (figure 4) and Virus Total (figure 3), and both determined the file was malicious. The file was uploaded into Any.run, it was determined to be malicious and also contain macros (figure 5).

Figure 3 Virus Total analysis on suspicious word document

Considering this, the threat actor may have spoofed the IP address to gain access to the network and attempted to download the malicious word document. I downloaded the zipped file on a windows 20 flare-vm, and unzipped it revealing the INVOICE PACKAGE LINK TO DOWNLOAD.docm file.

Figure 4 Hybrid Analysis, analysis overview of suspicious document

Figure 5 Any.Run analysis of the suspicious document

When the word document is opened from the temp folder, it initiates a powershell command which downloads a file from filetransfer.io, a malicious domain (figure 6). Furthermore, there were changes to registry keys associated with Microsoft office and Windows installer. Additionally, temporary files were created in the user’s AppData directory by Microsoft word and powershell processes which could be malicious activity.

Figure 6 Indicators of compromises

Figure 7 Potential threats associated with the malware

Conclusion

In conclusion, a medium alert receieve on March 14th 2021, for the attempted download of a Word document. The action was successfully blocked. The document was uploaded to multiple analyzers and was found to be malicious. Opening the suspicious file resulted in the downloading of a file via PowerShell from filetransfer.io. After the file was executed registry keys were modified and the temporary files were created in specific directories. These suspicious activities could be indicative of malicious behavior, warranting further investigation by a malware analyst to understand the full scope of the potential threat.

Figure 1 Details of the phishing alert

According to the information provided, on March 22, 2001 at 09:23PM, an event occurred in which a phishing URL was detected. The alert originated from the address 172.16.17.49, from host EmilyComp, username Ellie.

Figure 2 URL analysis results from Virus Total

Figure 3 URL analysis results from Hybrid Analysis

As shown in figure 2 and figure 3, the URL was determined to be malicious by VirusTotal and HybridAnalysis. VirusTotal had 9 security vendors flag the URL as malicious.

Figure 4 Event log

Inputting the source IP’s address into Letdefend’s Log management section provides several event logs. The event log of interest shown in figure 4, shows the malicious URL is destined to for port 80. Port 80 is an unsecure Hyper Text Transfer Protocol (HTTP), used to transmit and receive unencrypted web traffic. The Request URL uses HTTP, so it was sent to port 80. The action was not blocked,so the host computer will be contained (Figure 5).

Figure 5 Host Containment

On March 21, 2021 at 12:26 PM, phishing mail was detected. It originated from source address: aaronluo@cmail.carletion.ca and it’s SMTP address is 189.162.189.159. The email’s destination address is mark@letsdefend.io. The email subject stated COVID19 Vaccine.

Figure 1 Screenshot of the alert
—

Further analysis of the SMTP address resulted in the discovery of the destination address 172.16.20.3.

Figure 2 Screenshot of event details via the Log management dashboard

Inputting the destination address into LetsDefend’s EDR displays the host information. —

Figure 3 Screenshot of LetsDefend’s EDR

The email contained an attachment with a file hash and a password: infected. The MD5 hash is 72c812cf21909a48eb9cceb9e04b865d.

Figure 4 The suspicious email containing a file hash

The sender’s email address domain name was searched in Cisco Talos and returned the domain name belongs to an educational institution.

Figure 5 Information related to the sender’s email address domain via Cisco Talos

Further analysis of the domain name reveals it is located in Canada.

Figure 6 Domain name location via Cisco Talos

The zipped file was downloaded and it contained a Material.pdf file. Moving the file to desktop results in the file requesting the password: infected. The file was unzipped and uploaded in VirusTotal. VirusTotal found the file to be malicious. —

Figure 7 Analysis of the file via VirusTotal

To decrease the chance of a false positive, I uploaded the file to Hybrid Analysis. It also determiend the file was malicious.

Figure 8 Analysis of the file via Hybrid Analysis
—

##Conclusion

Email was found to contain a malicious attachment. The actions of the sender were blocked and the email was deleted.

Creates an attack surface belonging to the organization in order to produce intelligence specific to the organization.

This personalized attack surface allows the organization to gain visibility. Visibility can be a forgotten endpoint or a forgotten subdomain.

The main takeaway is the organization now know their inventories and know which assets to defend against.

Determining the Attack Surface

When creating the attack surface every facet is taken into account.

• For instance, subdomains,
• domains,
• websites,
• login pages,
• CMS applications,
• technologies used on websites,
• IP addresses,
• IP blocks,
• DNS records,
• C-level employee mails,
• network applications,
• operating systems,
• bin numbers,
• SSL certificates
• and swift codes

Domains

Given only the primary domain of the organization, the goal is to create the entire entity structure over this domain.

Sample scenario:

An asset inventory of Abanca, a bank located in Spain, will be created.

Main domain: Abanca.com

Related domains:

1. Find domains that provide redirects to the main domain
2. Use host.io, it provides all the domains hosted on the same IP, domains hosting the relevant domain within the website, other domains hosted by the domain within the website
3. Decide which domains belong to the organizationn and which don’t by checking the whois outputs of the domains or by looking at their content
4. To view all of the domains via the API, become a member, or
5. Find similar information in whois records of the primary domain we are working on by performing a Reverse whois lookup (Reverse by Org Name, reverse by Registrant Mail, etc.)
6. Use the reverse whois tool at viewdns.info or the whoxy.com tool
7. Check DNS records of relevant domain and reach other domains using the same DNS records with the “dig” command on the command line

Subdomains

Tools available to find subdomains:

• SecurityTrails
  • Can be used on the command line via hacktrails or API or queries can be made from the visual interface
• Aquatone
  • collects data and produces output by querying form multiple sources
  • Entering the necessary API keys in the configuration files for the resources that require API keys will increase the number of subdomains it will find.
  • Uses a scan module to check the activity of the subdomains it finds
  • Uses a takeover module to check whether there is a takeover vulnerability on the subdomains it finds
• Sublist3r
  • Runs on the command line and finds and outputs from multiple sources
• Assetfinder
  • Queries subdomains and obtains data from many sources

When searching for subdomains, get as much data from as many sources as possible.

Websites

To find websites, requests must be sent to the domains and subdomains we find.

Active websites are obtained by examining the domains and subdomains that respond to HTTP/HTTPS requests.

When all the domains are listed and scanne dby the “httpx” tppl, it will list all the domains that responf to http/https requests.

An alternative to “httpx” tools is to use “httprobe” tool, a tool that possesses similar functions.

Login Pages

Detecting websites with login pages can be done manually, however it is a time-consuming process.

To make the detection process easier, simple scripts can be written in “Python”

By sending requests and using the BeautifulSoup libraries in python, we can detect login pages for the websites we have.

For this process:

1. We need to check the background code of the login page and look for indicators that will give us a clue about whether there is a login page or not
2. We can ask the following question to determine whether the page is a login page or not:
   • Is the word “Login” or its corresponding phrase in any language possible on the page?
   • Are form tags used on the page?
   • Are there expressions such as “Username” or “Password” in the placeholder section of the input fields on the page?
   • Are there “Login” or similar expressions in the title or header of the page?
3. If the script we wrote parses the content in the response to answer to answer these questions, we can detect most of the login pages in a short time.

Technologies Used of Websites

Detecting technologies used on websites will be important for vulnerability intelligence.

Technologies used on websites can be detected using manual methods and multiple tools.

Wappalyzer tool can be used to detect technologies used on pages.

Alternatives to “Wappalyzer” are “Whatruns”, “BuiltWith” and “Whatcms”

To examine technologies used on websites manually, one could examine the source code of the page and make a technology detection by viewing the file paths of the theme belonging to thr content management system and libraries given in the code, specifically in the script tags.

A second approach would be to examine the header of the responses returned from the page from the developer console.

Information about the technologies used on the page can be displayed within the header of the returned responses.

IP Addresses

In order to detect IP addresses of domains and subdomains, the A records of the domains are collected or IP addresses are detected by sending a request and resolving it.

To detect all the active IP addresses contained in the IP blocks used within an organization, requests are sent to all the IP addresses in the block and the active ones are selected.

IP Blocks

IPs with the highest risk are contained within the IP blocks owned by the organization.

IP blocks can be detected by looking for patterns in the IP addresses obtained from the domains and checking the whois information of consecutive IP addresses to understand whether they belong to the organization or not.

A second approach is to search for keywords of an organization by using the org parameter on Shodan.

The org parameter is a search parameter used for the organization part of the IP addresses.

Alternatives to Shodan are Binaryedge and Zoomeye.

Online tools such as bgp.he.net can be used to detect blocks.

DNS Records

It’s important to monitor DNS records to detect unknown DNS record changes.

To detect DNS records, use Google’s dig tool or use websites like dnslytics.com

DNS records can also be accessed with the dig command on the command line.

C- Level Employee Mails

Senior executive emails compromises can result in disaster. Data transmitted within the mail traffic on a daily basis is crucial for the organization. It is essential to monitor corporate email traffic as well as personal emails.

Several tools frequently used to detect these emails include:

• SalesQL
• RocketReach
• Apollo
• ContactOut

These tools work as chrome extensions.

It is recommended to use a fake email address and fake LinkedIn account when using the tools.

Go to the person’s LinkedIn profile and click on the extension and the extension will list the e-mail addresses they can detect.

Network Applications and Operating Systems

Discovered services can be collected by querying the IP addresses via Shodan with passive scanning or they can be detected via active scanning.

Network applications and operating system detections can be made according to the responses to the requests sent to the open ports of previously removed IP addresses on the asset list.

Bin Numbers and Swift Codes

Most import assets to be monitored for matters such as the detection of stolen credit cards on the intelligence side, which are of particular interest to fraud teams in banks.

There public databases designed for the detection of bin number and swift codes such as:

• bincheck.io
  • Filter through bin numbers using the country and bank names
• freebinchecker.com
• bintable.com

Sites to detect Swift codes:

• wise.com
• bank.codes
• theswiftcodes.com

Obtain swift codes by making bank-based inquiries on these sites.

SSL Certificates

Most important factors for secure communication.

To determine if there is an SSL certificate on the domains that have been detected and add it to the asset list, utilize tools such as “Censys” and “crt.sh”

It is referred to as the “push” protocol because messages are sent directly from the sender’s e-mail server to the recipient’s e-mail server.

SMTP does not encrpyt the contents of the mesage by default, which leaves the contents of the message vulnerable to interception or modification. Additional measures such as TLS (Transport Layer Security) can minizse these weaknesses.

SMTP is a text-based protocol of commands and responses.

Some commmands used in the SMTP protocol are:

EHLO: Used by the SMTP client to authenticate itself during communication with serverand to obtain a list of commands supported by the server.

MAILFROM: Identifies sender’s email address.

RCPT TO: identifies recipient’s email address.

DATA: Specifies start of the header, body of email, and containes the text data to be sent after this command.

QUIT: End’s the SMTP client’s communication with the server ans closes the conection.

SMTP Port 25 vs. Port 587

Port 25

The default and oldest port of SMTP. It’s used for communication between email servers. Server-to-server communication

Security: Blocked or restricted by many Internet Server Providers (ISPs). Emails sent through port 25 are susceptible to spam and fraud. Port should be used to provide a secure way for users to connect to their own e-mail server.

Port 587

Provides a secure way for users to connect to their own e-mail server and send an email.

Security: Preferred port for sending email because it requires the use of encryption (SSL or TLS) to initiate messages, which provides an extra layer of security for user authentication and data integrity.

IMAP and POP3

IMAP (Internet Message Access Protocol) and POP3 (Post Office Protocol version 3)

IMAP

Manages emails on the server and allows users to access emails across mutliple devices. Changes are synchronized across all devices.

Security: Requires persistent server connection and is usually encrypted with SSL/TLS. It is recommended that strong authentication and encryption methods are used due to the risk of credetials being transmitted in clear text.

IMAP Ports

Port 143: starndard unencrypted port. Port is ususally encrypted with (STARTTLS)

What is STARTTLS? A protocol command used to initiate encryption in communication protocols that start as plaintext. Primary used in email and messaging protocols such as SMTP, IMAP, and POP3.

1. Protocol Upgrade: During an existing communication session, STARTTLS upgrades a plaintext connection to an encrypted one using Transport Layer Security (TLS) or its predecessor, Secure Socket Layer (SSL).

2. Command-Based: In protocols like SMTP, IMAP, and POP3 is a command that the client sends to the server to request and encrypted connection.

3. Encryption Activation: After the server acknowledges the STARTTLS command, communication channel is encrypted using TLS, providing confidentiality and intergrity for the data exchange.

Port 993: Provides a secure connection for IMAP and is used for TLS/SSL encrypted communications. Provides security by encrypting email traffic.

POP3

Downloads emails from the server and stores them locally, allowing access to emails without an internet connection. Messages are only viewable on the device there were downloaded.

Security: Encrypted with SSL/TLS, but not as flexible as IMAP. Risk of data loss can increase if no local backups are made.

POP3 Ports

Port 110: Standard unencrypted port for the POP3 protocol. Secure communication can be established by using STARTTLS.

Port 995: Provides for a secure connection for POP3. It used for TLS/SSL encrypted communications. It is recommended for secure email reception as it provides security by encrypting email communication.

### Comparison and Usage Scenarios

IMAP is more suitable for situations requiring constant synchronization and email access on multiple devices.

POP3 is ideal for users who have simle email needs and who usually use a single device to manage their email on a day-to-day basis.

Figure 1 Applying the smtp filter on a pcap file in wireshark

The SMTP session begins with the server indicating it is ready to proceed with communication by responding with response code 220. The SMTP command ‘EHLO’ identifies itself to the server and provides a list of commands supported by the server. Response code 250 is the server identifying itself (figure 2).

Figure 2 SMTP traffic from start to finish

Further inspection of the network traffic log indicates the email address that sent the email is : test@letsdefend.io.

Figure 3 Sender’s email address
—

The destination email address that receieved the email is: admin@ubuntuvm. Figure 4 Email address of the recipient

The source IP address that sends the ‘EHLO’ message in SMTP traffic is: 172.16.8.136 (figure 5). Figure 5 Overview of the filtered network traffic log