During an investigation, there are times you just need to step away, stretch your legs, and grab a snack. That’s exactly what I was doing, traversing my house – nibbling on some artisan toast, when my wife yelled out “Hey, are you Hansel or Gretel? You’re leaving a trail of breadcrumbs everywhere!” Now I don’t know if it’s the geek in me, but the mere mention of a breadcrumb trail made me immediately think of the Indicators of Compromise (IOCs) from an investigation we worked in the not-too-distant past. But unlike Hansel & Gretel, whose breadcrumb trail was intended to lead them home (not to evil), our IOC trail was intended to lead us directly to the evil. In a way, it was beneficial. So, with this in mind, let’s take a look at following the IOC crumbs as it pertained to a Business Email Compromise (BEC) investigation recently investigated by the Accenture Security – Cyber Investigations, Forensics & Response team. Some of the data has been redacted or altered to protect the individuals involved; however, the actual IOCs remain in their entirety.

So how does a Threat Actor compromise a business email system? Through a phish. Nothing new here. While the following email (see Figure 1) would raise flags for many, despite the seemingly legitimate “caution” statement at the bottom of the email, some items are not so readily apparent – especially when viewed with many default fonts such as Outlook’s default font of Calibri. Have a look at the email, then we’ll walk through our approach which included:

  • Email analysis (to include email source headers)
  • Open source research on identified IOCs
  • Root Cause Analysis (or access method)
  • Scope of the intrusion (to include the number of impacted accounts) 
  • Of note, there wasn’t a network breach, so this post just covers the BEC.

<<< Start >>>

Figure 1 Phish Email

<<< End >>>

Open-source research suggested “virutalpbx.com” is a valid domain. However, mousing over (not clicking on) the various hyperlinks within the body of the email (i.e., phone number, Play Audio, Replay Audio and Save Audio) revealed they all contained the link in Figure 2:

<<< Start >>>

Figure 2 Malicious Hyperlink

<<< End >>>

Continued research indicated this link redirected its victims to “voicemessagingline.azurewebsites[.]net” which appeared to be a legitimate link to set up cloud voicemail. Threat Stream Intelligence, however, suggested “azurewebsites[.]net” domains have been used as phishing credential harvesting website domains (see Figure 3).

<<< Start >>>

Figure 3 Threat Stream Intelligence

<<< End >>>

Further evidence indicated multiple users clicked the link and entered their credentials – bringing the BEC to fruition. But let’s get back to the phish email and those IOC crumbs.

Beginning with DNS logs, analysis revealed more than 20 users followed the link in Figure 2, evidenced by their respective DNS queries for the malicious domain. Table 1 reflects one DNS query example.

<<< Start >>>

Table 1 DNS Log Excerpt

<<< End >>>

Nothing nefarious jumps out when viewing the body of the email normally with Outlook (see Figure 4). However, it takes on a completely different look when the email source code is viewed through a Command Line Interface (CLI) (see Figure 5).

<<< Start >>>

Figure 4 Email Viewed via Outlook

<<< End >>>

<<< Start >>>

Figure 5 Email Header Viewed via *nix Command Line

<<< End >>>

Notice the obfuscation through letter substitution:

  • a lowercase “L” for an uppercase “i" in “OFFICE”
  • an uppercase “i" for a lowercase “L” at the end of “VoiceMail”

Armed with the IOC of “voicemaii” ending with a double “i" pattern, we can now employ a CLI stack of grep, sort and awk. This is not to be confused with the weightlifting ECA stack from back in the day (Ephedrine, Caffeine and Aspirin), although both stacks pack a powerful punch.

Let’s conduct a case insensitive “grep” of O365 Unified Audit Logs, looking for the string “maii”, followed by a pipe to “sort” the 4th field in reverse order. This field contains the time slice, and the subsequent output will be in chronological order. Finally, we’ll pipe this output to an “awk” statement in order to reorganize the comma delimited data while keeping the comma delimiter intact. This provides the succinct output shown in Figures 6 and 7. Of note, Figures 6 and 7 contain the same data, but viewed through a Linux CLI and Word document respectively to illustrate the obfuscation effectiveness.

<<< Start >>>

Figure 6 - output viewed from CLI

<<< End >>>

<<< Start >>>

Figure 7 - output text copied into Word document (obfuscation intact)

<<< End >>>

As we can see above, the first attempt at 7:30 contained the plural form of “VoiceMaii” and was quarantined. The reason for this quarantine was not determined during this analysis. But at 15:19 it was sent again, this time in the singular form, and it was successfully delivered to two different persons.

Another bit of information we had to work with was a verbal notification that the threat actor attempted to defraud the company out of 7.3 million dollars. However, a search of all data sources for “7.3” and “7,300,000” revealed negative results. Those search values are probably too specific so let’s broaden it just a bit and search for “7,3” and see what we get. Bingo! (see Table 2).

<<< Start >>>

Table 2 O365 Message Trace Log Reflection of Threat Actor IP Address

<<< End >>>

This is perfect. Not only do we have the subject line, but we also have the originating IP address. Additionally, the fraud attempt was actually for 7.35 million Dollars vice 7.3.
These are certainly some additional IOC breadcrumbs we can sink our teeth into (pun intended). Let’s start by following the attacker IP.

Calling upon our good friend grep once again, we search the O365 Message Trace logs for the nefarious IP while printing only the desired fields sorted by the first column as follows: >grep –F 23\.254\.244\.134 [log_filename].csv | cut -d"," -f1,2,6,10-13 | sort -k1.

Fantastic. This reveals another IOC crumb by way of an email thread to follow – subject lines containing the words “Wire Approval” as reflected in Table 3.

<<< Start >>>

Table 3 O365 Message Trace Logs Revealing New Thread

<<< End >>>

Before following the subject line thread, however, let’s go back to the O365 Unified Audit Logs and conduct a search for our Threat Actor IP Address now that we know it. The search reveals 17 user accounts were compromised and accessed (see Table 4).

<<< Start >>>

Table 4 O365 Audit Log Reflection of Malicious IP Address

<<< End >>>

From an Incident Response (IR) perspective these results are enlightening in that they identify more compromised accounts than originally believed by the client. This output also suggests that not all 20 plus users who followed the malicious link in the phish email were compromised. Surmise they didn’t follow the exploit attempt to fruition.

Digging a bit deeper into these connections, four different user-agents were observed within these connections as illustrated in Table 5.

<<< Start >>>

Table 5 User-Agents

<<< End >>>

Getting back to the subject line thread. A common denominator (reflected earlier in Tables 2 and 3) is the word “Wire” so let’s extract the Message Trace Log entries containing “Wire” to see what pops out.

We’ll use the following grep / cut / sort command: grep -i wire [multiple parsed message trace logs]  | cut -d":" -f2-7 | sort -k4

Table 6 details the results.

<<< Start >>>

Table 6 Message Trace Logs With New Thread

<<< End >>>

Not all hits were pertinent to this investigation, but one clearly stood out. The “Due Wire” email from a suspicious Hotmail account “pxxxxc@hotmail.com”. Now we have three email threads to follow: “Due Wire”, “Wire Approval” and “Incomplete Wire Form”. Looks like a good time to pop open some PSTs.

Let’s begin with the “Due Wire” thread (see Figure 8).

<<< Start >>>

Figure 8 Due Wire Email Thread

<<< End >>>

The email was sent to two individuals asking if the attached wire instructions were correct. The two individuals (we’ll refer to them as “K” and “B”) correspond to User 4 and User 5 respectively in Table 4. This email also introduced another previously unseen email address: “dxxxxxn@cxxxxxv.com”. We’ll make note of this for later.

Regarding the two suspicious email addresses, each were noted in previous breaches, once and ten times respectively, as illustrated in Figure 91.

<<< Start >>>

Figure 9 External Email Account Breaches

<<< End >>>

1https://haveibeenpwned.com 

Moving over to the “Wire Approval” thread, let’s first look at the exchange between “B” and “K” (see Figures 10 and 11).

<<< Start >>>

Figure 10 Wire Approval (request) from 'B'

<<< End >>>

<<< Start >>>

Figure 11 Wire Approval (approved) from 'K'

<<< End >>>

We see a request to approve a “wire for escrow” sent from “B” to “K”. This is followed by an approval from “K” ten minutes later. From the outside looking in, everything seems legitimate. Valid user accounts and all. However, remember what we saw earlier in the Message Trace Logs (Table 3 germane)? Each of these emails were spawned from the Threat Actor (TA) IP of 23.254.244[.]134.

In essence, the TA impersonated both “B” and “K” using their legitimate accounts to send the request from “B” followed by the approval from “K”.

Now let’s move over to the “Incomplete Wire Form” thread between authorized user “S” and the TA “B” (see Figures 12 and 13).

<<< Start >>>

Figure 12 Incomplete Wire Form (notification)

<<< End >>>

<<< Start >>>

Figure 13 Incomplete Wire Form (reply)

<<< End >>>

At this point, legitimate user “S” informed “B” that the form was incomplete. “S” also sent applicable fix actions as well as pointing to which drive to submit the form when completed. Unbeknownst to “S”, “B” was in fact a TA who went on to return an updated form. However, TA “B” claims access issues to the appropriate drive. Then it states the reason for sending the form directly to “S” is because “its [sic] almost cut off time.” There’s that “urgency” indicator we keep hearing about.

Six minutes later, “S” acknowledged receipt of the email, followed by another moments later indicating something was still missing, requesting a phone call (see Figures 14 and 15).

<<< Start >>>

Figure 14 Incomplete Wire Form (confirmation).

<<< End >>>

<<< Start >>>

Figure 15 Incomplete Wire Form (something missing)

<<< End >>>

Following the phone call request by “S”, TA “B” went quiet – not connecting nor sending any other correspondence. Interestingly, it was later learned the actual user “B” was at lunch during this timeframe.

At the end of the day, this fraud attempt didn’t work, but it was very close. and following the IOC crumbs helped bring that to light. It’s important to note, however, that the TA did their homework. With access to 17 email accounts, the TA found a legitimate wire request form to use. In addition, the TA discovered the actual approval limit of “K” which would strengthen the fraudulent form’s sense of legitimacy. And remember the email address we noted earlier from the “Due Wire” thread (Figure 8 germane)? It contained an email from the suspicious Hotmail account to “dxxxxxn@cxxxxxv[.]com”. This is the same email address used as the confirmation email on the fraudulent request form (see Figure 16). The Hotmail email could have been done to provide a sense of legitimacy to the email address.

<<< Start >>>

Figure 16 Fraudulent Request Form

<<< End >>>

The fraudulent request form also contained a cover letter that began with “Dear ‘K’, With regards to our phone conversation earlier today…”, and it concluded with “Send wire confirmation to the email dxxxxxn@cxxxxxv[.]com”.


Ultimately, all the account passwords were reset across the enterprise and the TA gained no further access. However, unlike breadcrumbs that you can sweep up and throw away, you can’t do that with IOC crumbs. Twenty days after this activity, the TA sent out another wave of phish email using the same IOC of letter substitution obfuscation (see Figures 17 and 18).

<<< Start >>>

Figure 17 - Phish Second Wave (viewed via Windows)

<<< End >>>

<<< Start >>>

Figure 18 Phish Second Wave (viewed via *nix CLI)

<<< End >>>

…It didn’t work.

BONUS CONTENT

1.0 MITRE ATT&CK© and Indicators

MITRE Technique MITRE ID MITRE Link Tactic IOC
Compromise Accounts: Email Accounts T1586.002 https://attack.mitre.org/techniques/T1586/002/ Resource Development N/A
Obfuscated Files or Information T1027 https://attack.mitre.org/techniques/T1027/ Defense Evasion Obfuscation through Letter Substitution (lowercase ‘L’ for uppercase ‘i’; uppercase ‘i’ for lowercase ‘L’ )
Phishing T1566 https://attack.mitre.org/techniques/T1566/ Initial Access You have (2) Pending VoiceMaiI
Phishing: Spearphishing T1566.002 https://attack.mitre.org/techniques/T1566/002/ Initial Access https://ctbatl.azurefd[.]net/voiceindex
Information: Spearphishing T1598.003 https://attack.mitre.org/techniques/T1598/003/ Reconnaissance https://ctbatl.azurefd[.]net/voiceindex

2.0 Data Sources

Artifacts Analyzed  Purpose
DNS Logs Tracks domain name resolution requests and can be used in BEC to see how many users clicked on malicious link by searching for malicious domains
O365 Message Trace Logs Contains key information about inbound and outbound email traffic
O365 Unified Audit Logs Contains all activities in O365 such as logins inbox rule activities (create, modify, delete)
Phish Email Initial analysis of content attachments and metadata to identify key IOCs (IPs, malicious links in content of email and/or attachments unique style/key words) serves as pivot
PST Contains email account’s email messages and Outlook items. Can be used to track activity associated with malicious email including content metadata and attachments

3.0 Tools

Tools Used Purpose
Operating System Command Line Interface Parse raw log data
OST PST Viewer Examine and analyze email
pffexport (via SIFT Workstation) Carve out email components such as messages, outlook headers. internet headers, attachments etc.
Splunk Parse and Timeline raw log and PST data

Disclaimer: The information in this blog post is general in nature and does not take into account the specific needs of your IT ecosystem and network, which may vary and require unique action. You should independently assess your specific needs in deciding to use any of the tools mentioned. The tools listed in 3.0 Tools are not Accenture tools. Accenture makes no representation that it has vetted or otherwise endorses these tools and Accenture disclaims any liability for their use, effectiveness or any disruption or loss arising from use of these tool.


If you have an incident or need additional information on ways to detect and respond to cyberthreats, contact a member of our CIFR team 24/7/365 by phone 888-RISK-411 or email CIFR.hotline@accenture.com.

Accenture Security helps organizations build resilience from the inside out, so they can confidently focus on innovation and growth. Leveraging its global network of cybersecurity labs, deep industry understanding across client value chains and services that span the security lifecycle, Accenture helps organizations protect their valuable assets, end-to-end. With services that include strategy and risk management, cyber defense, digital identity, application security and managed security, Accenture enables businesses around the world to defend against known sophisticated threats, and the unknown. Follow us @AccentureSecure on Twitter or visit us at www.accenture.com/security.


Accenture, the Accenture logo, and other trademarks, service marks, and designs are registered or unregistered trademarks of Accenture and its subsidiaries in the United States and in foreign countries. All trademarks are properties of their respective owners. All materials are intended for the original recipient only. The reproduction and distribution of this material is forbidden without express written permission from Accenture. The opinions, statements, and assessments in this report are solely those of the individual author(s) and do not constitute legal advice, nor do they necessarily reflect the views of Accenture, its subsidiaries, or affiliates. Given the inherent nature of threat intelligence, the content contained in this report is based on information gathered and understood at the time of its creation. It is subject to change. Accenture provides the information on an “as-is” basis without representation or warranty and accepts no liability for any action or failure to act taken in response to the information contained or referenced in this report.


This document makes reference to marks owned by third parties. All such third-party marks are the property of their respective owners. No sponsorship, endorsement or approval of this content by the owners of such marks is intended, expressed or implied.


Copyright © 2021 Accenture. All rights reserved.

Casey Gately

Manager – Security

Subscribe to Accenture's Cyber Defense Blog Subscribe to Accenture's Cyber Defense Blog