top of page
Search

Security Operations Center(SOC) is one of the most crucial components in Cyberdefense for any new-age enterprises. No matter how many costly and popular cybersecurity tools have been purchased by companies, there's not much worth if there are no efforts towards centralized log collection and a SOC Team which can draw understanding from, and take actionable steps from the vast pool of collected logs from various log sources. But a question arises; can a SOC achieve it’s true potential without being updated on the latest cyberattacks and vulnerabilities?


Consider a situation where a SOC Team member is going through the logs from a particular log source and is coming across an attack pattern, for eg. multiple login failures from different geolocations seen in firewall logs. Seems to be a dictionary bruteforce attack on the firewall management interface. Also consider that subsequently, they're also going through a threat intelligence article which details an attack camapign which targets their firewall vendor's management interface via a critical vulnerability. The article also contains the malicious iocs and other details of the attackers, the details of the vulnerability which is targeted, the patch details for the vulnerability, and actionable steps to prevent a major incident in future. The SOC Team member is alarmed by the critical exposure of the firewall management interface to public and works closely with Firewall Team to limit public access via a VPN. They also make sure firewall has the latest patches. Additionally, they perform threat hunt for the malicious IoCs and block if any found within the company environment. They also create rules and dashboards to automate these detections in the future. This is where the power of Threat Intelligence comes in. While earlier it was just a bruteforce attack detected on firewall logs, with added threat intel coverage, its context expanded above and beyond and gave lots of actionable steps to the SOC Team to secure their enterprise.


What Really is Threat Intelligence?

So before going further, lets have some basic understanding about threat intelligence and its usecases.

In simple terms, threat intelligence is the art of knowing who your attackers or potential attackers are, and predicting their next move. Threat intelligence comes in various forms such as Tactical Threat Intelligence, Operational Threat Intelligence and Strategic Threat Intelligence. From a SOC perspective, more relevant are the former two, i.e Tactical(IoC-based) and Operational(TTP-based) Threat Intelligence. Since tactical threat intelligence is IoC-based(Indicators of Compromise), its more volatile. IPs, domains, file hashes etc. will keep on changing as the threat actor can easily do so in order to cover their tracks. So having the relevant and up-to-date information is very important in tactical threat intelligence. Nowadays, what many SOC teams are doing wrong is, overly relying on third-party TI feeds integration and thinking that that's enough to tick the TI box. The problem with this approach is that, many of the feeds ingested or iocs received might not be relevant to you and will only help to increase the overall log ingestion into your SIEM tool. It could be outdated data, for eg. a "malicious" IP which is 3 months old and which is no longer used by the attacker, or a domain which targets an entirely different country or industry from yours. These are irrelevant data for your organization. Operational Threat Intelligence relies on attacker TTPs(Tactics, Techniques & Procedures) which has more lifespan compared to IOCs. This is because TTPs are basically attacker behaviours which doesn’t change overnight. For eg. A threat actor using a specific phishing lure for initial access, using a specific C2 protocol for data exfiltration etc. The best practice for SOC teams is to use a combination of tactical and operational threat intelligence for maximum effectiveness.


Relevant Threat Intel

Threat Intelligence in its true form is always relevant and that's particularly so when some of the below conditions are met:

- Relevant to your industry: For eg. A specific rasomware targeting healthcare industry.

- Relevant to your region: Cybercrimes trageting your company's operational region.

- Technology-specific threats: Critical Vulnerabilities present or attacks targeting your technology stack, be it the operating system used, Windows or third-party applications deployed etc.


How to gather Threat Intelligence

The best thing to have is your own threat intelligence team which actively researches the open, deep and dark web for gathering data on critical threats. If your company doesn’t have that bandwidth, lots of proactive threat intel teams are present across the world which disseminate critical threat research data for free on a periodic basis. Some of the best threat intel teams in the industry are:


Each of these vendors are leaders in threat research and their articles go so much in-depth into the vulnerabilities, how they’re exploited, related iocs etc. If mapped rightly to the parameters for relevant threat intel which was discussed previously, these info can provide invaluable inputs to companies to improve their overall security posture.


How to Leverage Threat Intelligence in SOC Monitoring?

Even though threat intelligence is one of the most powerful assets for any blue team, its one of the most underutilized powers in many companies. Even to the extent that many cybersecurity companies simply see it as a marketing exercise which is limited to sending Weekly Threat Intel Newsletters to their existing/prospective clients. But here's a fundamental thought which might help reiterate the importance of threat intel. If not well-informed about the latest cyberattacks or vulnerabilities, how efficient will defenders be? Is the purpose of SOC just to check the compliance boxes and get drowned in redundant false positive alerts? If the answer is a big NO, let’s discuss some ways to effectively leverage the valuable information extracted from threat intelligence to empower the SOC operations.


Threat Hunting with IOCs

The easiest and the best way to start leveraging threat intelligence is performing a threat hunt with the IOCs collected from the threat intel. This is the tactical threat intel area which we previously discussed. In this stage, we check whether there were any connection attempts(allowed/blocked) from the malicious IPs  towards our company environment, any malicious hashes(files) observed in the endpoint logs, malicious domain connections observed from any of the endpoints etc. If allowed connections are observed, further investigation is required including checking the bytes transferred, any return connections, file executions, file drops in unusual locations, further inbound/outbound connections targeting vulnerable ports etc. Remediation actions can start with blocking the malicious iocs and then taking further steps as required according to how the investigation unfolds.


Threat hunting focused on TTPs

Here, we leverage the Operational Threat Intelligence which was discussed earlier wherein we focus on the attacker's tactics, techniques and procedures(TTPs).

Consider a threat actor who uses a specific phishing lure, i.e Christmas themed giveaway emails(Initial Access). The email contains a Word file attachment which when opened  contains Macros which need to be enabled to view content. Upon enabling macros, a powershell script gets downloaded and run. The PowerShell script checks user privileges(Discovery), disables the real-time protection in Windows Defender(Defense Evasion), attempts to download and install the WinSCP software(Execution), compresses and sends data to a remote server using WinSCP(Data Exfiltration). Many of these tactics/techniques are common across threat actors and can be spotted using threat hunting rules which contains command-line keywords from these activities.

For eg., disabling real time monitoring is performed using the following command in PowerShell:

Set-MpPreference -DisableRealtimeMonitoring $true

Such attempts can be spotted by searching for commandlines in Sysmon/EDR logs with the keyword "DisableRealtimeMonitoring"

 

Very obviously, such activity might overlap with valid admin activity which is why hunting and log analysis shouldn’t be limited to just a few commandlines or IP connections, but the search time should be broadened to analyse what happened before and after the suspicious activity. If it’s a case of compromised admin account, most probably you’ll see something unexpected/absurd happening unlike a normal admin account.


Detection Rules

Now consider we have performed the threat hunting based on relevant threat intel for our company and made sure that there's no imminent threat targeting our firm. But what if, something happens later when we're not performing hunting? What if the SOC Team has shifted its focus to another major threat actor which is targeting its geographical area and the previous threat actor takes advantage of this opportunity? So we need a means to automate the process of getting alerted when it matters, i.e we need Detection Rules. Detection rules can also be IoC-based or TTP-based. IoC-based rules might be helpful to detect a specific threat-actor presence in company environments but are often short-lived. TTP-based rules can prove helpful to detect different threat actors since as discussed earlier, many TA's share similar tactics/techniques.


Dashboards

Building dashboards to monitor attack trends is another helpful way to evaluate the overall security posture of your firm. Dashboards provide a bird's eye-view into those key metrics which helps both the SOC Team and the C-Level Executive Team alike. SOC Team gains visibility into critical vulnerabilities and threats looming over their enterprise, which can be further investigated in-depth via log analysis and threat hunting as well as can be automated using detection rules. CISO can take major strategic decisions based on the visible company exposure and by identifying areas which require higher cybersecurity investment.

 

Its high time to make a major shift from viewing threat intelligence as a fashionable, marketing term which is seldom used realistically in cyberdefense to being an essential powerhouse of a SOC Team. Relevant and actionable threat intel coupled with well-devised SOC processes will be a real force to be reckoned with! Its time to de-glamorize and expose the cybercrime space which is filled with crooks who rejoice on others’ miseries and thinks they can get away with it. Threat-intel powered SOC shows the way forward!!

 
 
 


In Parts 1 and 2, we covered two areas within static analysis of a phishing mail. In this final part, we're moving on to Dynamic Analysis, where we execute and interact with the malware embedded in malicious mails.


What is Email Dynamic Analysis?

Dynamic analysis of phishing mails is used to examine and understand the behavior of phishing emails in real-time. Dynamic analysis involves studying the behavior of an email when it is opened or interacted with, as opposed to static analysis, which examines the email's content and code without executing it.

Here are some key aspects of phishing email dynamic analysis:


Behavior Monitoring

Analysts observe the behavior of the email when opened or interacted with, including any attempts to connect to external servers, download malicious content, or execute malicious scripts.

Sandboxing

Phishing emails are often analyzed in a controlled environment known as a sandbox. Sandboxing involves running the email in an isolated environment to monitor its actions without risking harm to the actual system.

Code Execution Analysis

Analysts examine any scripts or code embedded in the email to understand their purpose and potential malicious activities. This includes looking for attempts to exploit vulnerabilities or execute malicious commands.

Payload Analysis

If the email contains attachments, dynamic analysis involves examining the payload (e.g., malicious files, documents, or executables) to understand their functionality and potential impact on the system.

Dynamic URL Analysis

If the email includes hyperlinks, dynamic analysis involves checking the behavior of these URLs when clicked, including redirection to malicious sites or attempts to download malicious content.

Malware Detection

Dynamic analysis helps identify and detect any malware associated with the phishing email. This can include traditional malware or more sophisticated types such as ransomware.


Dynamic Analysis Tools

Let’s explore some effective tools which can be utilized to perform dynamic analysis on phishing mails.

Virtual Machines

Virtual machines hosted in personal devices are one of the preferred ways for analyzing malware. You can use the virtualization vendor of your choice(Eg. VirtualBox, VMware etc.). For OS, its suggested to have Linux as the host OS and Windows as the guest OS. Most malware targets Windows, so it’s the best choice for guest OS for successfully simulating malware infection. Also, since the host OS is Linux, the malware will be ineffective even if it escapes the guest OS into the host.


ANY.RUN

ANY.RUN is one of the leading online malware sandbox solutions in the market. The advantage of Any.Run is that it is fully interactive, i.e suppose an excel file needs to be uploaded and then macros needs to be enabled within the file to activate malware, all that could be performed safely within Any.Run’s online Virtual machine. Also, there are lots of customization options for the online VM such as OS version, browser, network etc. Free version has some limitations such as a time limit of 1 min with extra added time of max. 4 mins, availability of public task only(which means all browsed data will be public), only available OS-Windows 7 to name a few. 

SquareX

SquareX is a revolutionary cybersecurity tool with multiple features such as disposable browser, disposable file viewer and disposable email. Using SquareX is as simple as opening a new tab in your browser. SquareX just requires you to open their browser extension or web app, spin up their disposable browser or file viewer and then start analyzing the malicious URL or attachment which you’re after. Each session lasts for 10 mins, can be extended for additional 10 mins for any number of times.

Browserling

Browserling is an online cross-browser testing tool which can be used as a URL sandbox. Enter the suspicious URL which needs to be analyzed, select the OS, browser and browser versions of your choice and proceed. Free version is limited to Windows 10 OS, 3 min. time limit etc. to name a few.


Sample Analysis

Now, lets perform a sample analysis on a malicious mail with one of the dynamic analysis tools which we discussed above.


The email pretends to come from Amazon support and mentions that an “imaginary” card associated with mail recipient’s Prime membership is no longer valid and that the card details needs to be updated. The email uses urgency tactic by stressing that the updation should be done within 1 day. The email further directs the recipient to open the email attachment for details.

We’ve downloaded the .docx attachment to a VM and for further protection, we’re using Any.Run sandbox for opening the attachment and viewing details.

The document contains similar information as seen in the email body. 2 URLs have been included for updating the (“imaginary”) card details. When we hover over both the links, its clear that both are the same and they direct to “qrco[.]de/beGfog” which is a QR Code Generator website. We click on the link and it opens in a browser within Any.Run sandbox.


The webpage mentions that  “The QR Code Campaign has been disabled for some reason”. This indicates that this webpage had previously hosted a QR code which, when scanned might have taken the victim to the attacker-controlled website setup to steal victim’s credentials. Later, the malicious website might have got taken down by law enforcement or deleted by the attacker themselves due to which the QR code has got disabled.

Finally, we’ve successfully completed the various ways of analyzing phishing mails. The evolution of phishing has taken a concerning turn with the incorporation of AI, enabling attackers to create more convincing and adaptive phishing campaigns. Highly-sophisticated phishing, despite its complexity, has become easily accessible due to the widespread availability of phishing kits and phishing-as-a-service options available in the dark web, facilitating cybercriminals in orchestrating attacks with minimal technical expertise. But the fact is that however sophisticated a phishing attempt is, there’ll still be some loopholes which helps uncover the threat as in the case of any criminal act. It is imperative for cybersecurity professionals to master diverse methods of analyzing phishing mails rather than solely relying on grammatical errors or hovering over links. Such knowledge will empower even a common end user of the internet to make informed decisions on the basis of rightly identifying phishing threats without seeking external assistance.


For any concerns or queries, hit me up on LinkedIn or Twitter

 
 
 


In Part 1, we explored ways to analyze the email body of a phishing mail. While the email body is the core content of the email which is easily visible to an end user, email headers form the metadata of the email which sheds more light into the origin, route and legitimacy of the email. In Part 2 of this 3-part series, we're focusing on the email headers and ways to decipher and analyze them.


What is an Email Header?

An email header is a set of metadata that accompanies an email message, typically hidden from the recipient's view. It contains information about the message's transmission, routing, and the sender and recipient's email addresses. Email header analysis is a crucial technique in the field of phishing analysis and email security which involves dissecting the information contained within the email header to uncover valuable insights about the message's origin, path, and authenticity. Understanding email headers is essential in identifying and mitigating phishing attacks, as attackers often manipulate or forge these headers to deceive recipients.


Key fields in an Email Header


Return Path: The email address where non-delivery notifications are sent.


Received: A series of headers detailing the email's route through various email servers. The bottom "received" entry will show the initial server which handled the message.

 

Authentication Results: Shows the status of email authentication protocols - SPF, DKIM, and DMARC.  They help ensure that the email came from a legitimate source and hasn't been tampered with along the way.

 

  • SPF (Sender Policy Framework): SPF is like a bouncer for your email. It specifies which mail servers are authorized to send emails on behalf of your domain. When an email claiming to be from your domain arrives, the receiving server checks with SPF to see if it's on the VIP list. If not, it might get bounced like an uninvited guest at a fancy party.

 

  • DKIM (DomainKeys Identified Mail): DKIM signs your emails with a digital signature. It's like sealing an envelope with a wax stamp; when the recipient gets the email, they can verify the stamp to make sure it hasn't been tampered with. This ensures that the email came from the claimed sender and hasn't been messed with during transit.

 

  • DMARC (Domain-based Message Authentication, Reporting, and Conformance): DMARC is like the supervisor of SPF and DKIM. It tells the email receiver what to do if SPF or DKIM checks fail. It adds an extra layer of control and helps prevent phishing and spoofing. DMARC also provides a way for the email sender to get reports about email authentication failures, allowing them to fine-tune their setup.

 

Subject: Subject of the email

 

From: Sender of the email

 

To: Receiver of the email

 

Date: Date and Time of mail delivery to recipient

 

Reply-To: Specifies the email address to which replies should be sent. In many cases, "From" and "Reply-To" addresses are the same. If these addresses are different, there can be both legitimate and malicious scenarios for the same.

Legitimate scenario:

  1. Automated Notifications: Automated systems or services might send emails on behalf of a user (From), but replies may be directed to a support team or specific contact (Reply-To).

  2. Marketing and Communication Campaigns: Marketing emails may come from a general marketing address (From), but replies may be directed to a customer support or sales team (Reply-To).

 

Malicious scenario:

  1. Spoofing and Impersonation: An email might appear to be from a known entity (From), but replies to the email may be directed to the attacker's address (Reply-To). This is a technique used in business email compromise (BEC) attacks.

 

X-headers: The "X-" prefix in email header fields typically denotes custom or non-standard headers that were added by specific email systems, applications, or servers for various purposes. These headers are not standardized by the Internet Engineering Task Force (IETF) and may vary between different email services or software. Some of the commonly seen X-headers are mentioned below.

  • X-Mailer: Indicates the email client or mail transfer agent (MTA) used by the sender to compose the email.

  • X-Priority: Specifies the priority of the email (e.g., High, Normal, Low).

  • X-Originating-IP: Displays the IP address of the sender.


Email Header Analysis Tools


Now, let's explore some tools which can be leveraged to effectively analyze email headers.

 

MX-Toolbox

Mx-Toolbox is a great suite of various email security products, "Email header analyzer" being one of them. Just copy-paste the email header to the Email Header Analyzer textbox and click on "Analyze Header".


Email Header Analyzer provides detailed view of the following:


-Email authentication(SPF/DKIM/DMARC Compliance)


-Email relay information(extracted from "Received" headers which lists down the various SMTP mail servers through which the email was relayed, related IPs and received time)

 

-Different email headers and their values in a tabular format


Also, note that there's an option at the bottom of the page to "Permanently forget this email header". In case of privacy and confidentiality concerns, use this option to remove any traces of the email header from MX Toolbox servers.

 


PhishTool

PhishTool is a powerful phishing email analysis tool. It helps organize the vast information contained in an email file into different logical sections and enables in-depth analysis of different aspects of a suspicious mail.

 

PhishTool divides email header information neatly into different sections such as Headers, Received Lines, X-headers, Security, Attachments and Message URLs. There is direct integration to VirusTotal, WhoIs services.

 

“Headers” section shows the basic header information such as “From”, “Display Name”, “To”, “Reply-To”, “Return-Path” etc.


“Received lines” section shows the sequence of hops between different SMTP servers till the email reaches its final destination.

 

“X-headers" section details the non-standard headers in the mail which was previously discussed.

 

“Security” section includes SPF, DKIM and DMARC authentication results of the email.


“Attachments” and “Message URLs” sections contain details regarding the email attachments and included URLs.

 


 

Sample Analysis

Now, as we're aware of the various email headers and ways to analyze them, let's do a sample analysis on the email headers of a suspicious mail.

 

To view the headers for the above mail, see the email raw file available at:

 

The email seems to come from Microsoft and mentions that an unusual sign-in activity was observed on the email recipient's account from Moscow, Russia. The email further suggests to report the user if this wasn't done by the email recipient themselves.


First, let's have a check on the "Display name", "From", "Reply-To" and "Return Path" addresses.


Here, the "Display Name" is "Microsoft account team". But, from the very first look on the "From" and "Reply-To" addresses, its clear that the mail isn't from Microsoft. Still, we can have an additional check on the domain mentioned in From address, "access-accsecurity[.]com". WhoIs details show that it belongs to "Name Strategies LLC" which is a telecommunications company based in Colorado, United States. Reply-To address is a personal mail account belonging to "gmail.com" domain which is a big red flag. "Return Path" is the mail to which non-delivery notifications are sent. The WhoIs search for the "Return Path"(thcultarfdes[.]co[.]uk) shows that this site is not even registered. This indicates that this is a forged email header. Attackers use a variety of tools and custom scripts to forge email headers. Another method seen is, using compromised SMTP servers or exploiting specific vulnerabilities present in those servers to forge email headers.


 

Now, lets have a check on the "Received" headers.

 

As discussed earlier, the order for Received headers is from bottom to top. Here, we can see the email passed between 4 different email servers. We don't have much details(eg. location) related to these servers apart from the fact that these are Microsoft SMTP servers. The first "Received" header mentions the IP "89[.]144[.]44[.]2"(This is the originating IP of the email) which belongs to GHOSTnet GmbH, Germany and has been reported multiple times for Phishing/Email Spam/Spoofing according to AbuseIPDB.


 

Now, let's have a look on the authentication section of the header.


SPF, DKIM and DMARC haven't been set which is highly suspicious. This means that there is no protection against spoofing for the sender's domain.

 

So, in this case, there are multiple red flags which lead us to the conclusion that the email is not from Microsoft and is indeed a phishing mail.


As part 2 of this phishing analysis series completes, we're done with the email header analysis. Let's go to Part 3 - Dynamic Analysis!!!


For any concerns or queries, hit me up on LinkedIn or Twitter

 
 
 
bottom of page