8
Analyzing a Real-World Threat

It’s time to put the information we’ve discussed throughout this book into action. This chapter takes these tools and methods and applies them to a real-world example. The data you will analyze is from an actual attack executed by a nation-state in 2013. While dated, it provides a solid model for how these analyses unfold in real life.

The Background

Imagine you are a security analyst for a think tank that conducts economics and political science research. A senior executive at your firm has received a suspicious email about an upcoming conference. This executive, who provides policy advice to nations throughout the Asia-Pacific region, is unsure whether the email is legitimate and is asking for guidance.

You have the following goals:

  1. Determine if the email is fraudulent. Identify evidence to support a claim that it is malicious or legitimate.
  2. If it’s malicious, identify the attack chain, detailing the sequence of events taken to compromise the target step-by-step.
  3. Identify the tactics, techniques, and procedures; the infrastructure; and the malware associated with the attack. If possible, attribute the attacker.
  4. Use the information you’ve learned to form actionable intelligence you can use to better protect your organization. Create a threat profile detailing the actor behind the attack based on what you found during the investigation.

Since the potential attack originated with a suspicious email, let’s start our analysis by examining it.

Email Analysis

As an analyst, you will likely encounter many malicious or spam-related emails. But not every email you investigate will be malicious, so it is essential to identify evidence to prove or disprove your claims.

Using the spear-phishing analysis methods and best practices learned in Chapter 6, analyze both the header and the email body to determine if it is legitimate. The header information is the most important of the two, as it will help you determine if the email came from the sender it claims to, but the body may also contain useful information.

Header Analysis

       Received: from inttx.mofa.go.jp (unknown [10.36.230.34])
by SOGMIMV01.mofa.go.jp (Postfix) with ESMTP id 1DA40340063
Fri, 20 Sep 2013 16:31:58 +0900 (JST)
Received: from intrx.mofa.go.jp
by inttx.mofa.go.jp (smtp) with ESMTP id r8K7Vw9o007065
Fri, 20 Sep 2013 16:31:58 +0900
Received: by intrx.mofa.go.jp (smtp) with ESMTP id r8K7Vvio007062
Fri, 20 Sep 2013 16:31:57 +0900

Received: from mailrx.mofa.go.jp
by mail.mofa.go.jp (smtp) with ESMTP id r8K7Vibi011043
Fri, 20 Sep 2013 16:31:44 +0900
Received: from mail-vb0-f67.google.com
by mailrx.mofa.go.jp (smtp) with ESMTP id r8K7Vegb011034
Fri, 20 Sep 2013 16:31:41 +0900
Received: by mail-vb0-f67.google.com with SMTP id g17so8659vbg.2
for <multiple recipients>
Fri, 20 Sep 2013 00:31:39 -0700 (PDT)
X-Received: by 10.59.9.138 with SMTP id ds10mr5127258
ved.5.1379662299622
20 Sep 2013 00:31:39 -0700 (PDT)
Received: by 10.58.97.169 with HTTP
Date: Fri, 20 Sep 2013 11:31:39 +0400
Message-ID: <[email protected]
gmail.com>
Subject: List of journalists accredited at the APEC Summit 2013
From: Media APEC Summit 2013 <[email protected]>
To: REDACTED
Content-Type: multipart/mixed
boundary=047d7beb9ac847ba7204e6cba922
Content-Type: text/plain
charset=ISO-8859-1
Content-Type: application/vnd.ms-excel
name="APEC Media list 2013 Part2.xls"
Content-Disposition: attachment
filename="APEC Media list 2013 Part2.xls"

From the bottom up, the information in the header is presented in chronological order, beginning with the sending mail server. Each server the email transits, from sender to receiver, will have an entry in the header.

The first important pieces of information you should notice are the filename, name, Content-Type, and Content-Disposition fields. These provide information about the attachment included in the email. The attachment is a Microsoft Excel spreadsheet named APEC Media list 2013 Part2.xls. In the 1990s, when email first became popular, it was possible to add an attachment, represented by the filename field, and manually type in its name, which was then displayed in the name field. The idea behind this approach was the sender may want to display a more human-friendly name or description of the attachment. However, email providers stopped allowing this capability due to its misuse by spammers, and now both fields are identical within the header.

Next, take note of who received the email. The To field can be useful in cases when there are multiple recipients. Often you can identify a pattern in the recipients, such as a shared industry or professional affiliation. You can also conduct open source research to determine where the email target list originated. Many times, attackers obtain their target list from information they find in open source data, such as a conference attendee list, for example. You may be able to identify the source they used, which in some cases may shed light on attacker interests. For instance, if the target list originated from a conference surrounding technologies used to develop hybrid turbine engines, you could theorize the technology may be of interest to the attacker. The From field displays the account from which the email originated, [email protected].

The subject, List of journalists accredited at the APEC Summit 2013, tells us the email’s general topic. The topic of the email is especially valuable if the email is malicious and targeted. Persistent attackers will often send several waves of phishing emails attempting to compromise targets. If you find that these email subjects share a common theme, you can use this information to discover other malicious emails with a similar theme. These emails might originate from the same attacker even if they are sent from another sender address.

The Message-ID is exclusive to each email. If you have several emails from the same attacker, check to see if each has a unique Message-ID. If any share the same ID, the email is fraudulent. Sometimes, attackers use software to create fraudulent emails that reuse the same Message-ID. The Date field tells you when the email was sent and provides the originating mail server’s time zone. You can use the time zone and date later when conducting attribution. The Received field appears throughout the header. Each time a mail server processes an email, it leaves its hostname, time, and date in the header.

Some mail servers provide an IP address in addition to the hostname in the mail server record. In that case, you can check hosting records to identify organizations that registered domains hosted on the IP. If the infrastructure does not map to the organization you expect, there may be a problem. Gmail, however, uses a nonroutable private IP address, making it useless for investigative purposes.

Moving your way up through the header, continue to review each Received field. The hostname shows the email was sent from a Google mail server, mail-vb0-f67.google.com, and went to multiple recipients. Knowing the registered name of the mail server and its associated domain, google.com, you can validate if the sending email address is sent from legitimate Google infrastructure. If not, this field would indicate the email is fraudulent and using a spoofed email address. This validation is more important when the sending email address is a private company using its own email infrastructure instead of a public email provider like Gmail. The other information in the entry you want to note is the timestamp: Fri, 20 Sep 2013 00:31:39 −0700 (PDT). Besides knowing when the email was sent, you also learn it originated from a mail server from a region using Pacific Daylight Time.

The next entry in the header tells us the Gmail server sent the email to mailrx.mofa.go.jp on Fri, 20 Sep 2013 16:31:41 +0900. Certain regions of Asia use the +0900 time zone; you can use a search engine to learn which exact countries.

Next, the email is transmitted through several mail servers within the mofa.go.jp infrastructure. To identify who owns this domain, conduct a Whois query for mofa.go.jp, which returns the following record:

whois:        whois.mofa.go.jp
status: ACTIVE
remarks: Registration information: https://jprs.jp/
created: 1986-08-05
changed: 2022-11-09
source: IANA
Domain Information:
[Domain Name] MOFA.GO.JP
[Organization] Ministry of foreign affairs
[Organization Type] Government
[Administrative Contact] KN45712JP
[Technical Contact] KN45712JP
[Technical Contact] DW3422JP
[Name Server] ns1.mofa.go.jp
[Name Server] ns2.mofa.go.jp
[Name Server] ns3.mofa.go.jp

Based on the record, you learn the mail server belongs to the Ministry of Foreign Affairs associated with Japan’s government. Remember that the executive within your organization works with countries in Asia, like Japan. Next, look at the body of the email for additional clues.

Email Body Analysis

Review the body of the email to identify anything that seems amiss. Remember, small clues may not be a smoking gun, but they add up when you start to link information later in the analysis process. Figure 8-1 displays the body of the email as the target would see it.

Screenshot of an email with the subject line “MEDIA APEC Summit 2013” and the body “Dear Sir/Madam, The list of journalists accredited at the APEC Summit 2013 in Bali, 7-8 October 2013. Thanks with best regards.” Contains an attachment called “APEC Media list 2013 Part2.xls”

Figure 8-1: Suspicious email targeting an executive at your organization1

You should always check three things in the email body:

  1. Does the sending email address identified in the header match the signature in the email body? In this case, the email sender is [email protected], and the signature block address in the email body is also [email protected]. The addresses match. If you find these addresses to be different, it is a good sign the email may not originate from the person portrayed in the email body. You would be surprised by how often an attacker creates a fake account but uses the legitimate contact details of the individual they are spoofing to populate the email signature. When this happens, the signature block information won’t match the account used to send the email.
  2. Does the email alias match the name or title associated with the sender’s address and information in the signature? Here, the sending address [email protected] uses the alias “Media APEC Summit 2013.” Because the alias presents a human-friendly identifier, a savvy attacker may use the alias field to mimic the sender’s official name, title, or, worse, another email address. This is a common tactic used by adversaries to deceive their victims; note, as shown in Figure 8-2, that only the alias, not the email address, is visible when the victim opens the email. Remember always to validate the email sender, as an attacker can use the legitimate email address they’re spoofing as the alias.
    Screenshot of an unopened email with the sender name “Media APEC Summit 2013” visible

    Figure 8-2: APEC Summit–themed alias used to mask the Gmail address used to send the email

    In this case, using a professional title, such as “Media APEC Summit 2013,” as an alias for a free webmail account is suspicious. The organization behind a professional summit would likely have its own infrastructure and not use a free webmail account. Using a name like “Media APEC Summit 2013” as the alias with a Gmail or any free webmail domain is a tactic often seen in fraudulent emails.

  3. Is the domain used to send the email affiliated with the company or organization the email claims to be affiliated with? Review the information in the signature, and note the included domain apec-2013.org. You’ll need to validate that this domain is legitimate and owned by APEC. If APEC owns the domain, the email sent to your organization is likely fraudulent, since the legitimate summit media organizer would have sent the email from that apec-2013.org domain. If the domain is not legitimate, you still need to determine what legitimate domain is associated with the summit to validate if the email should originate from a Gmail address.

OSINT Research

Next, take the information identified in the previous steps and see what you can learn about the email’s validity, the email’s sender, the summit, and the APEC domain found in the signature. To start, let’s do a simple search engine query for the summit, as shown in Figure 8-3.

The first result returned appears to be the primary domain for the summit. However, this domain, apec2013ceosummit.com, isn’t the same as the one listed in the body of the email, apec-2013.org. This is also suspicious. You can conclude from this that either the domain in the email is fraudulent or the conference has multiple domains. You must investigate further before you can make the determination.

Google search page with the search query “APEC 2013 summit” and the results “APEC CEO Summit Indonesia 2013 | 5 -7 October 2013 Bali” and “2013 APEC Ministerial Meeting”

Figure 8-3: Web query for the APEC Summit

Before clicking any links, you should validate that the domains returned by the search engine and listed in the email are not malicious. Query the Whois records associated with each domain. The following is the domain registration record for apec-2013.org:

Domain Name:APEC-2013.ORG
Created On:29-Aug-2012 21:57:35 UTC
Last Updated On:24-May-2013 09:59:16 UTC
Expiration Date:29-Aug-2014 21:57:35 UTC
Sponsoring Registrar:CV. Jogjacamp (R1830-LROR)
Status:CLIENT TRANSFER PROHIBITED
Registrant Name:Andi Superi
Registrant Organization:Nulines
Registrant Street1:Kp rawa Roko 008/003 Bojong Rawa Lumbu
Registrant City:Bekasi
Registrant State/Province:Jawa Barat
Registrant Postal Code:17116
Registrant Country:ID
Registrant Phone:+62.620000000
Registrant Email:[email protected]
Admin Name:Andi Superi

Here is the domain registration record for apec2013ceosummit.com:

Domain Name: APEC2013CEOSUMMIT.COM
Created on: 2012-08-13 09:15:36 GMT
Expires on: 2014-08-13 09:15:37 GMT
Last modified on: 2013-05-06 02:23:07 GMT
Registrant Info:
Indika
Indika Energy
Jakarta
JKT, -
Indonesia
Phone: +673.7186377
Fax..:
Email: [email protected]
Last modified: 2013-02-12 07:24:20 GMT

Note the registrant addresses and associated contact information for each. You can use the addresses to identify additional information associated with each domain, if necessary; in this case, we’ll assume no other registered domains associated with those addresses exist to provide further evidence.

Next, check VirusTotal to see if any antivirus vendors detect malicious activity on either domain. Figure 8-4 displays the results for the domain apec2013ceosummit.com.

Screenshot from VirusTotal showing the score 0/66 and the message “No security vendors flagged this URL as malicious”

Figure 8-4: VirusTotal results for apec2013ceosummit.com

Repeat the process for the second domain. VirusTotal should tell you that neither domain is malicious. Now it should be safe to visit the domains. You can use various methods to conduct research safely, but at the least, make sure to use an isolated browser and VPN when you review the websites. Figure 8-5 shows the home page for domain apec2013ceosummit.com.

After browsing, you should conclude that this domain is the legitimate website for the summit. Remember, the email mentioned journalists attending the summit and used the alias “APEC Media Group 2013.” If you can identify that a real summit media email address exists, you can say with high confidence the email is fraudulent. There are two ways to do this quickly. You can do a Google search by looking for the word media present on the apec2013ceosummit.com domain with the query "media" OR "Press" site:apec2013ceosummit.com. Alternatively, you could manually look on the website for a media section. A search engine query is always safer than visiting a website that is part of an attack, even if you don’t believe it to be malicious. Still, some websites prevent search engines from crawling and capturing their data. When a search engine query does not return results, you will need to manually search the domain for the media contact information. In this case, doing so leads you to the page shown in Figure 8-6.

Screenshot of the APEC summit web page showing Vladimir Putin speaking at a podium and below it is an image of Wishnu Wardhana and the message “Welcome message from the APEC CEO Summit Chair”

Figure 8-5: The www.apec2013ceosummit.com website2

Web page titled “FAQ: Media Registration” containing the text “MEDIA GUIDELINES-FREQUENTLY ASKED QUESTIONS: For general media-related questions, contact the CEO Summit Media Team (media@apec2013ceosummit.com)”

Figure 8-6: Summit media contact email address

This is the evidence we needed to validate that the summit’s email address for media communication is different from the address used to send the suspicious email ([email protected] versus [email protected]). Even without the email header, you could determine the email is fraudulent based on the information found in this open source data.

Next, you need to analyze the attachment to determine if it is malicious. If it is, you need to identify what it does, how it does it, and what benefit it provides to the attacker. For example, if the malware steals credit card information, you’ll treat it differently than if it’s designed to provide an attacker remote access into the environment.

Lure Document Analysis

First, using Cuckoo Sandbox, run the sample attachment. Figure 8-7 shows the “Summary” section information.

Screenshot of an info box titled “Summary” and containing the fields Size, Type, MD5, SHA1, SHA256, SHA512, CRC32, ssdeep, and Yara

Figure 8-7: Cuckoo Sandbox “Summary” section for analysis of the lure document included in the phishing email

Document the sample’s attributes, such as the compile time, SHA256 hash, and filename. You will use these later to find additional information about the sample.

In this case, since the file is a document and not an application compiled with code as an executable, the compile time isn’t relevant. The time and date information you can use, however, including the “Last Saved Time/Date” found in the “Type” field: Wednesday, October 31, 2012. This gives us a more accurate timeframe for when the lure document was modified. Keep in mind, though, that the attacker may have stolen or acquired a legitimate media contact spreadsheet and weaponized it for their malicious purposes after the fact. The date may reflect when the document was last saved by the legitimate author and not necessarily when the attacker altered it for attack purposes. Still, it is good to have for your timeline of events.

Next, review the “Detection” section of the analysis report. This section shows the names of antivirus signatures that detect the sample as malicious. Figure 8-8 displays the results.

As you can see, several signatures identify the document as malicious. These signatures can also tell you, at a high level, what the malware does. For example, Symantec detected the file as a Trojan.Mdropper 2, for which Symantec’s website provides the following explanation:

Trojan.Mdropper is a detection name used by Symantec to identify malicious software programs that exploit Microsoft Word or Excel vulnerabilities to drop other malware on to the compromised computer.3

This is a great clue, because now you know the sender of the APEC-themed spreadsheet intended to trick the victim into opening the document to install malware. Other detection names, such as Exploit.CVE-2012-0158.Gen, provide further details about the exploit used in the attack 1. If you look up CVE-2012-0158,4 you’ll learn it is a Microsoft Office vulnerability. When opened, the attachment takes advantage of the document vulnerability to execute shellcode.

Now we’ve identified the following components as part of the attack chain:

  1. The phishing email: This includes the lure document, which contains the exploit CVE-2012-0158.5
  2. The command-and-control infrastructure: Based on the detection information, you now know the attacker uses infrastructure in conjunction with malware. You will need to identify and analyze the infrastructure.
  3. The second-stage malware: Again, the signatures indicate that the lure document is a dropper that delivers malware. You need to find the malware and analyze it.
Screenshot of a results list containing a list of vendors on the left and signature names on the right

Figure 8-8: Cuckoo Sandbox “Detection” section of analysis report for the APEC lure document sample e8d3f1e4e0d7c19e195d92be5cb6b3617a0496554c892e93b66a75c411745c05

Identifying the Command-and-Control Infrastructure

There are a couple of ways to find the command-and-control infrastructure. If Cuckoo analysis doesn’t capture the information, you could manually conduct static analysis of the malware; however, that isn’t easy, and it requires specialized training and experience. Still, sometimes static analysis is the only way to analyze malware if it has antianalysis components.

In this case, the malware doesn’t have antianalysis functionality built into its design. The “Behavior” section of the Cuckoo analysis report provides details on the malware communications. (Other commercial malware analysis solutions like VirusTotal and Hybrid Analysis also have a behavioral component of their analysis reports.) The behavior information includes details of IP traffic and DNS resolutions seen in the malware communication; of files the malware opens, creates, or deletes; and of any shell commands run:

IP Traffic:
81.169.145.82

DNS Resolutions:
software-update.org

Files Opened:
C:WindowsSystem32winime32.dll
C:WindowsSystem32sechost.dll
C:WindowsSystem32imm32.dll
C:Program FilesCommon Filesmicrosoft sharedOFFICE11MSO.DLL
C:WindowsAppPatchsysmain.sdb
C:Program FilesMicrosoft OfficeOFFICE11EXCEL.EXE

The first thing you should note is the IP traffic and the DNS resolution, which identifies the infrastructure with which the malware communicates. You will want to remember the address 81.169.145.82 and domain software-update.org. Later, you will use the information to pivot, search, and identify other components of the attack. The domain name alone should stand out as suspicious. Why would a media contact list for an Asia-based economic summit communicate with a software update domain? This does not make sense.

Identifying Any Altered Files

Next, always review the “Files Written” component of the “Behavior” section. Most malware will open a backdoor, deliver malware, or both, and when a dropper introduces malware onto the operating system, the malware will usually be named after a file or operating system component to avoid suspicion. However, if you know the parent file is malicious, it makes it much easier to identify.

Files Written:
C:UsersAdministratorAppDataLocalMicrosoftWindowsTemporary Internet FilesContent.MSO2460C3F1.wmf
C:UsersAdministratorAppDataLocalTempdw20.t
C:Program FilesInternet Explorer etidt.dll
C:AppDataRoamingMicrosoftWindowsStart MenuProgramsStartup

Files Deleted:
C:UsersAdministratorAppDataLocalTemp~DF9300481277D842F4.TMP

Shell Commands:
rundll32 C:UsersADMINI~1AppDataLocalTempdw20.t,#1

Let’s review the four files created by the malware and written to the operating system.

The first is a Windows Metafile Format (WMF) file placed in the Temporary Internet Files folder, which is the designated file space used to store temporary data about the browsing session used by the victim browser, Internet Explorer.

The second file should raise a red flag, because it is saved in the AppData folder, which exists to store configuration settings and data used by system applications. Microsoft uses the dw20 filename for its error reporting tool, which is either an executable (.exe) or a dynamic link library (.dll) and does not include the t seen here in the filename. The strange filename and the placement into the AppData folder are evidence something is not right and warrants further investigation. It is likely a file delivered by the malware. If you are unfamiliar with the names of various operating system files, such as dw20, and their functions, a search engine query of the filename will tell you exactly what it does and where the file is located by default.

Next, the suspicious dw20.t error reporting tool appears to use the victim’s browser (Program FilesInternet Explorer) to deliver a file named netidt.dll. Here, the adversary appears to have made a mistake. Spelling is essential when you are masquerading a malicious binary as a legitimate operating system resource. There is no netidt.dll component of the operating system, but there is a netid.dll. Similar to the previous file, there is no t in the legitimate filename. The operating system uses the actual netid.dll in conjunction with error reporting; it’s a System Control Panel Applet known as the Network ID Page.6 Again, note the file for further research to validate it is malicious.

The last file writes to the Windows Startup directory. This is a common tactic seen in malware to ensure its persistence on the host system. Applications in the Startup directory run every time the operating system boots. This way, if the victim or defensive software removes the malware, it will be reinstated the next time the system boots.

Keep in mind that nation-state malware often uses zero-day exploits, which go undetected. This is why reviewing and mapping out exactly what the suspect binary does when executed can provide you with additional clues to determine if you should conduct further analysis. It is important to understand you cannot always rely on virus detection and other security applications to identify a binary as malicious.

Analysis of Dropped Files

Next, you need to confirm both dw20.t and netidt.dll are malicious and identify their role in the compromise. The analysis report for the lure document generated by Cuckoo includes a “Dropped Files” section, which provides details on both binaries. Figure 8-9 shows each.

F08009a
Two screenshots, each showing a web page titled “Dropped Files.” The first shows information for a file named dw20.t The second shows information for netids.dll. The information includes the files’ size, type, and the fields MD5, SHA1, and SHA256.

Figure 8-9: Dropped Files, dw20.t and netidt.dll, originating from the lure document

Again, before continuing, document the hashes and names associated with each file. Once you confirm the files are malicious, you will add them to the indicators of compromise associated with this investigation. You can use the indicators of compromise for both defensive and analytical purposes.

Next, review the files in the same order in which the parent file used them. Based on the sequence of events, dw20.t likely behaves like a dropper to deliver netidt.dll.

Analysis of dw20.t

Thirteen antivirus signatures 1 detect the dw20.t binary as malicious (Figure 8-10). In reviewing the first few detection names, you should validate the binary is a dropper 2. Additionally, Cuckoo identified several detection names, including “Win32/Sednit.D trojan” 3. These represent the names of the signatures that detected the file.

Note the detection names for now. We will conduct further research into the Win32/Sednit.D trojan once we finish reviewing both files. The “Summary” section also identifies the file as a dynamic link library, meaning it provides code and data to programs within the Microsoft operating system.7 The report also shows that the actual filename is dw20.t.dll.

Screenshot labeled “File has been identified by 13 AntiVirus engine on IRMA as malicious (13 events)” and containing three vendor names, along with their detection names

Figure 8-10: Detection names from the “Summary” section of the dw20.t analysis report generated by Cuckoo Sandbox

Whenever you review Cuckoo analysis for a portable executable (PE) or a dynamic link library (DLL) file, you’ll want to look at the “Static Analysis” section of the report. (This section is not the same as the static analysis we spoke of earlier involving an analyst reverse engineering the malware; it’s just the name Cuckoo gave this section of the report.) This section provides the compile time, PE imphash, and languages identified in the file. The APEC lure document we reviewed previously did not include this information because it is not a PE or DLL. Figure 8-11 shows the “Static Analysis” section for dw20.t.dll.

Screenshot of a web page titled “Static Analysis” that includes the text field PE Compile Time with the value 2013-07-23 09:59:11, the text field PE Imphash containing a long string value, and a Resources table with the following fields: Name, Offset, Size, Language, Sub-language, and File type

Figure 8-11: “Static Analysis” section of the Cuckoo report for dw20.t.dll

The compile time 1 appears legitimate, as it is close to the time of its use in the attack. The imphash 2, or import hash, is a value “calculated for all the library DLLs that are used in PE executable and also its import functions usage in that executable.”8 Similar to a file hash, you can use an imphash to digitally fingerprint executables. Note this information, because you can use the hash to identify other files that share the same imphash in commercial malware repositories. Any language code set 3 found within the binary is listed, too. The files’ creators can select this language set, so it often represents the human language that the developer speaks. In this case, no formal language set was chosen, so the field is marked as neutral.

Analysis of netidt.dll

Review the same information for the netidt.dll file, shown in Figure 8-12. The information from the “Summary” and “Status Analysis” sections of the report have been condensed and combined for learning purposes.

Screenshot of a Cuckoo web page. Shows the summary section for the file netidlt.dll including the Size, Type, MD5, SHA1, and SHA256 fields, as well as the identified signature names. Also shows the Static Analysis section, including the PE Compile Time, PE Imphash, and Resources sections.

Figure 8-12: Cuckoo analysis of netidt.dll

Like the previous file, the report lists the filename netidt.dll and associated file hashes, as well as the antivirus signatures that detect the file, Win32/Sednit.B and Trojan-Downloader.Win32.Sofacy, which you will research shortly. You also capture the compile time and imphash.

You should also note something new, not seen in the other binaries: the presence of Russian in the binary’s code. Never assume this definitively indicates the adversary’s spoken language. Developers often reuse open source code written by other people to support functions within their software, while some adversaries will intentionally use another language’s code set while developing code to mislead researchers. Therefore, it is important to remain unbiased until you’ve analyzed all information to get the bigger attribution picture.

Signature Detection Clues

Now it’s time to further research the signatures that detect the malware discovered in the previous steps. Here is a list of the signatures you need to review:

  • Win32/Sednit.D trojan
  • Win32/Sednit.B
  • Trojan-Downloader.Win32.Sofacy
  • Infostealer.Sofacy

Searching the web for each specific signature reveals that the malware specimens all have similar functionality. For example, Figure 8-13 shows Symantec’s detection report for Sofacy.9

Web page titled “Infostealer.Sofacy” with information about the malware, including antivirus protections against it, files and registry keys the malware might create when executed, and email clients from which the malware attempts to steal information

Figure 8-13: Infostealer.Sofacy detection information

Each signature involves exploiting the operating system and then downloading and installing a backdoor to steal information from the victim system. Often, when it comes to advanced malware, the signature names will include the name of a malware family. If you search for a specific signature, as we did, it will tell you the specific functionality associated with the malicious file, but if you search for the malware by the variant name, you can learn a lot more information.

You don’t have to be an expert to recognize the malware variant names found in a signature. When unsure, simply remove the generic signature terminology like trojan, downloader, and win32, and conduct a web query for the remaining terms. Experienced analysts may not have to conduct this step, especially if they have reverse engineering capabilities to dissect the malware.

Once we remove the generic terminology, we are left with two terms, Sednit and Sofacy. Conduct a web search for pages that used these terms in 2013. Figure 8-14 shows the results.

Google search page with the query Sednit OR sofacy. Contains several results with the terms “Fancy Bear APT28” and “Russian-speaking APTs” circled

Figure 8-14: Search query results for the terms Sednit and Sofacy

Note that the terms Fancy Bear, APT28, and Russian-speaking APTs appear in the search results. Researching these terms and reviewing the content reveals that the Sofacy/Sednit malware was custom developed for use by an advanced Russian nation-state attacker, named Fancy Bear and APT28 by security vendors CrowdStrike10 and Mandiant,11 respectively. This, and the malware functionality discovered in your analysis, provides a much clearer picture of the attack and who is behind it.

The open source research you conducted also revealed that the Sofacy/Sednit malware is associated with only one attacker. Because of this, you should try to identify other recent Sofacy/Sednit samples, as the attacker could use additional related malware to target your organization in future attacks. This step is important to perform when it comes to nation-state attackers, especially if the malware is not prevalent outside of these targeted attacks. If, instead, the malware is common and detected by a generic signature like Backdoor.Trojan, for example, you’ll likely identify many malware variants, making it far less valuable to your investigation.

But Fancy Bear is likely to continue trying to compromise your organization when it realizes the current attempt failed. The easiest way to find related samples is to search public malware repositories for samples detected as Sofacy or Sednit. Check VirusTotal, Hybrid Analysis, and Joe Sandbox for this. Then try searching for each sample’s imphash in each repository. Commercial sandboxes allow for advanced searches, too. Each has operators you can use to craft more advanced queries. You can review the documentation at each sandbox provider’s website to learn more about them.

After conducting a basic search, you identify an additional 61 Sofacy/Sednit samples originating from the same attacker submitted to various sandboxes over a three-year period. When you search the repositories for an entire malware variant, you will get both recent and dated samples. Many of these won’t be related to your attack; regardless, if an advanced attacker targets your organization, you will want to identify as many indicators as possible to increase your chances of detecting future activity. To prioritize the samples discovered, look at the compile time for each and make a shortlist composed of any binary created in the past 90 days.

Infrastructure Research

When you reviewed the “Behavior” section of the lure document analysis report earlier, you observed malware communicating with the domain software-update.org and the IP address 81.169.145.82, which likely hosted the domain at the time of communication. Since defensive software identifies the malware as malicious, you should assume the domain software-update.org is, too, until proven otherwise. Next, you will pivot on the registration and infrastructure information to find other related domains from the same attacker. Taking information from your attack and using it to find related threat data is a process known as pivoting.

The first thing you want to do is check the domain registration. Often, people use privacy protection to mask the domain’s actual registration data, but on occasion, bad guys make mistakes and create the domain for a brief time without using a privacy protection service. While most sites keep only the most recent record, services like DomainTools keep historical records associated with a domain. If you have access to DomainTools, check the historical registration around the time of the malicious activity.

The domain software-update.org was associated with malicious activity in 2013, when the attack took place. However, a new registrant took over the domain for legitimate purposes once it expired. The information used to register software-update.org is displayed here:

Domain Name: SOFTWARE-UPDATE.ORG
Updated Date: 2013-08-14
Creation Date: 2013-08-14
Registry Expiry Date: 2014-08-14
Registrar IANA ID: 1086
Domain Status: clientTransferProhibited
1 Registrant Organization: Andre Roy
2 Registrant Street: France
Registrant City: Paris
Registrant State/Province:
Postal Code: 75017
Registrant Country: FR
3 Registrant Phone:+490.61750
4 Registrant Email: [email protected]

Fortunately, in 2013, when the adversary acquired the domain, they did not use privacy protection, which would mask the registration information, making it useless for tracking purposes. Note the name Andre Roy 1, the associated phone number 3, and the email address [email protected] 4. Again, you can use the information to search for other domains from the same registrant. Also, take note of the Registrant Street field 2, which incorrectly lists the street as France. When you register a domain, you provide the information that populates the record. Entering the street address as France might have been a mistake. Alternatively, an attacker could have fabricated the information to avoid using an actual street address.

Finding Additional Domains

Let’s see what else we can learn about our attacker. Specifically, we should use OSINT techniques and sources to see what other infrastructure shares the name and email address used to register the command-and-control server software-update.org. If this is an advanced or a nation-state attacker, there may be a much bigger attack campaign underway. Identifying additional infrastructure or malware can help you identify the campaign’s scope.

You could use Google search operators (intext: "[email protected]" OR "[email protected]" OR "andre roy") to mine through data for other websites with related registration information. Keep in mind, today the registration for all these domains has changed and would not return these results; however, in 2013–2014 it returned the domains shown in Table 8-1. In conjunction with a web query, if you have a subscription to https://whoisology.com/, you can query current and historical records associated with an account. At the time of the activity, the [email protected] email address registered 17 additional domains.

Table 8-1: Domains Registered with the Andre Roy Persona

Domain Registrant
academl.com [email protected]
bulletin-center.com [email protected]
changepassword-hotmail.com [email protected]
changepassword-yahoo.com [email protected]
eurosatory-2014.com [email protected]
evrosatory.com [email protected]
googlesetting.com [email protected]
link-google.com [email protected]
software-update.org [email protected]
update-hub.com [email protected]
us-mg7mail-transfer-vice.com [email protected]
us-westmail-undeliversystem.com [email protected]
ya-support.com [email protected]
soft-storage.com [email protected]
Software-update.org [email protected]
set121.com [email protected]
product.update.com [email protected]

If the attacker created the Andre Roy email address to register software-update.org, other domains registered with the same address should also be associated with the same attacker. Additionally, many of them are suspiciously named to mimic software and password-related websites, which is a tactic primarily used in fraudulent activity.

Passive DNS

Now that we have identified additional domains, we want to map them out to their hosting infrastructure to learn as much as we can about our attacker. To do this, take each of the andre_roy-related domains you found in the previous step and check them against passive DNS records. Figure 8-15 shows the passive DNS query and results for the command-and-control domain software-update.org.

Repeat the process for each domain and note any IP address associated with the domains at the time of the activity. Since software-update.org is the only domain seen in the attack against your organization, you don’t know the attack timeframe for the other domains you identified. Instead, review their registrant records and note the date at which the Andre Roy persona registered each. You should also document any IP address hosting an andre_roy-registered domain seen after this date.

Screenshot of a user interface labeled “DNSDB Scout” set to a tab called “Standard Search.” Tab includes a Domain field set to “software-update.org,” a Bailiwick field left blank, and a Record type field set to A.

Figure 8-15: Passive DNS results for software-update.org obtained from Farsight DNSDB12

After doing so, you identify 14 unique IP addresses hosting the 17 identified attacker-related domains: 81.169.145.82, 84.246.123.242, 67.23.129.252, 66.96.160.151, 66.96.160.142, 65.175.38.200, 62.210.90.114, 46.183.217.194, 31.221.165.244, 23.227.196.122, 193.109.68.87, 173.194.121.36, 101.99.83.142, and 80.255.3.98.

Next, reverse the search and look at each of the 14 IP addresses to identify other domains they host. This may sound repetitive, but it is the best way to find additional infrastructure hosted on the same IP address as the domain of interest. Once again, the time and date are important. You care only about the records of the infrastructure that correspond with the timeframe of the attack.

After reviewing passive DNS records for all domains and IP addresses, you identify one IP address, 23.227.196.122, that hosts three suspicious domains, as shown in Figure 8-16.

The domains on the IP address 2 are interesting, because all look fraudulent, and two of the three appear to use a typosquatting tactic, intentionally misspelling or using similar-looking characters to spell out a domain. For example, academl.com uses an l and not an i 1. Attackers use the tactic to fool the victim into thinking they are clicking a link to the legitimate domain, which visually looks similar to the authentic domain. While you still need to conduct further research to validate that the domain is malicious, the typosquatting tactic should be a red flag.

Diagram showing four DOMAINS: 1) academl.com, labeled “Passive DNS Query #1” and connected with an arrow to the IP address 23.227.196.122; (2) academl.com, (3) eurosatory-2014.com, and (4) Tolonevvs.com all connected with an arrow to the IP address 23.227.196.122, labeled “Passive DNS Query #2.”

Figure 8-16: Passive DNS results for the domain academl.com and IP address 23.227.196.122

A web query for the academl.com domain leads to the actual domain academi.com (with an i and not a l). When spelled correctly, the legitimate domain academi.com is a website for an American-based private military company formerly known as Blackwater. The company primarily provides protection and defense work for the U.S. government.13 Searching the web for the second domain, eurosatory-2014.com 3, returns results for eurosatory.com, the legitimate website for a “Defense and Security Global Event” conference organized by the Commissariat Général des Expositions et Salons du GICAT, a subsidiary of the French Land and Airland Defence and Security Industries Association GICAT.14

Based on appearance alone, tolonevvs.com 4 looks like someone used vv in place of the letter w. Sure enough, searching the web returns results for the legitimate domain tolonews.com, which describes itself as “Afghanistan’s First 24-Hours News, Current Affairs, Business, Regional & World news Television Network.”15 The fact that the IP address 23.227.196.122 only hosts what appear to be spoofed domains should be an indicator all three are likely malicious. Even if they are not, the attacker may have created them for future use in attacks. Researching the registrant records associated with each, you see that two of the three domains, academl.com and eurosatory-2014.com, are registered to the Andre Roy registrant address. However, the third domain, tolonevvs.com, is registered by an unknown email address, [email protected]:

Domain Name: TOLONEVVS.COM
Updated Date: 2014-05-07
Creation Date: 2013-07-01
Registry Expiry Date: 2015-05-07
Registrar IANA ID: 303
Domain Status: clientTransferProhibited
Registrant Organization: Aksnes Thomas
Registrant Street: Sweden
Registrant City: Vaxjo
Registrant State/Province: Kronober
Postal Code: 35321
Registrant Country: SE
Registrant Phone:+46.480448382
Registrant Email: [email protected]

In addition to sharing infrastructure with the Andre Roy domains, the tolonevvs.com domain registrant information provides a hint that the same individual created both. Similar to the software-update.org domain, the Registrant Street field incorrectly lists a country and not a street address. This is a minor error, but it is also uncommon to see in legitimate registrant records. More importantly, it is a human mistake made by the individual who first registered each domain.

Similarly to the previous steps you used to enumerate domains, you should conduct web queries, perform Whois and Whoisology searches, and then check passive DNS records to find infrastructure associated with the aksnes.thomas persona. Figure 8-17 displays the aksnes.thomas domains discovered.

Diagram of the email address aksnes.thomas@yahoo.com connected to the servers nato.nshq.in, yandex-site.com, tolonevvs.com, militaryinf.com, bostondyn.com, nshq.in, and update-zimbra.com

Figure 8-17: Diagram detailing domains associated with aksnes.thomas account

Visualizing Indicators of Compromise Relationships

Now that you’ve collected a substantial amount of data, visualizing it can greatly assist your cyber investigation. Visualizations allow you to identify relationships and patterns between threat-related entities and indicators of compromise. They also help show how the attacker used each indicator in the attack. If you are asked about the investigation next year, you may not remember every detail. A visualization will make it easy for you or another analyst to understand how the “dots” connect and why.

To find stronger evidence, you need to compare the two clusters of domains from each registrant address with one another. To identify relationships that may not be obvious when looking at the data in text format, use Maltego to display the data visually. Figure 8-18 shows the results.

Diagram showing the connections between many domains registered to similar email addresses or hosted on the same IP addresses

Figure 8-18: Diagram showing the IP address and name similarities between both registrant addresses created with Maltego

Visualizing the data helps you discover more substantial evidence. The domain googlesetting.com, registered by Andre Roy, resides on the same IP address as another almost identical domain, google-settings.com, registered by Aksnes Thomas. Both domains spoof legitimate Google infrastructure, and both have the same registrant pattern seen earlier of using a country in place of the registrant street. Additionally, your initial domain and infrastructure research connected academl.com (Andre Roy) and tolonevvs.com (Aksnes Thomas) to 23.227.196.122, the first IP address we reviewed.

Now you have shared infrastructure involving multiple domains from each registrant. Additionally, the infrastructure hosts nearly identical domains, each registered by a separate persona, one of which registered the command-and-control domain, software-update.org, seen in the attack against your organization.

You now have enough evidence to support and defend the theory that both registrant personas and the associated infrastructure are controlled and created by the same attacker.

Findings

As you conclude the investigation, it is time to document your findings. You started this investigation with a single spear-phishing email and attachment. You went through investigative tasks and applied an analysis model to gather, pivot, analyze, and document the results of your findings. Continuing this process led to the discovery of 22 domains in total associated with 14 IP addresses belonging to the attacker’s infrastructure, as shown in Table 8-2.

Table 8-2: Domains and Registrants Associated with Your Investigation

Domain Registrant
academl.com [email protected]
bostondyn.com [email protected]
bulletin-center.com [email protected]
changepassword-hotmail.com [email protected]
changepassword-yahoo.com [email protected]
eurosatory-2014.com [email protected]
evrosatory.com [email protected]
google-settings.com [email protected]
googlesetting.com [email protected]
link-google.com [email protected]
militaryinf.com [email protected]
nshq.in [email protected]
set121.com [email protected]
soft-storage.com [email protected]
software-update.org [email protected]
tolonevvs.com [email protected]
update-hub.com [email protected]
update-zimbra.com [email protected]
us-mg7mail-transfer-vice.com [email protected]
us-westmail-undeliversystem.com [email protected]
ya-support.com [email protected]
yandex-site.com [email protected]

By the end of your investigation, including the malware found in the phishing email, you identified 64 malicious samples associated with the attacker. You also learned about the functionality and detection of Sofacy/Sednit malware, the malware family used in the attack against your organization. Table 8-3 displays an excerpt of the 64 hashes associated with the malware.

Table 8-3: Sofacy Malware Hashes

SHA256 Malware family
7170b84d38ad7509b1df1d2eddb332def4ffe7fa5d6272776abff01f06edc346 Sofacy/Sednit
fecf8751f19e3c6f172f9fc99083d2e847ccfdf13c6fa18b24349bc2822fe812 Sofacy/Sednit
763ccc997e6dbfc142317ec9e5b210d2f817520bbee748a8df24bffb5720fa76 Sofacy/Sednit
1f4e644f3a708d742eb88410bce83af058f8ad2491d100482a8bc5212390ddf5 Sofacy/Sednit
3c603225dca720fd2a6a3d5141f4dd136ebdef9d9293bcf7c090f1cdf92380d7 Sofacy/Sednit
54c9932629cb227c698ba7bc350df0c5a453b8d27d35abdccdfa5d1d77a173fe Sofacy/Sednit
a09fbe96fa92824000836275ba23ac242b3435d0df81ae5b912f515d65887429 Sofacy/Sednit

Using the tactics and methods taught throughout this book, you have taken a single email and malicious attachment and unfolded an entire nation-state operation!

Creating a Threat Profile

One more important step still remains: you must take everything you have learned about the attacker and create a threat profile. You’ve learned a lot about the tactics, techniques, and procedures; malware; infrastructure; and behaviors associated with a Russian-based nation-state attacker. Now you should share the information with other defenders and make the threat data you collected into actionable intelligence.

Remember that the threat profile should be short and concise. A common mistake analysts make is to use a threat profile to document all known information about a specific attack. The complete information should go into a threat report, not a threat profile, which should establish only the basic information necessary for an analyst to become familiar with the threat. This way, when an analyst or defender detects similar malicious activity in the future, they’ll more quickly identify that they are dealing with an advanced nation-state attacker.

Also, the data you found in the attack against your organization should always take precedence over data sourced from a third party. In other words, focus on what you know and can validate in the activity relevant to your organization. Use third-party reporting to fill information gaps only when you trust the source.

This appears to be a well-resourced adversary with interest in the 2013 APEC Summit. You believe, based on the malware and the large number of global leaders attending, that espionage is likely the campaign’s objective. You also learned the adversary reuses domain themes across their infrastructure, registered with two email accounts.

You learned the adversary used Gmail to send spear-phishing emails and weaponized legitimate documents, likely downloaded from the summit website, to use in attacks. You also identified the malware used in the attack as Sofacy/Sednit, designed for information theft. Done correctly, OSINT research combined with solid analytic techniques can provide a wealth of information about your adversaries and help you better understand and defend against threats. In this use case, you identified the adversary’s infrastructure and TTPs, which will help you to better defend against them in the future. More importantly, you identified the group behind this attack is APT28, a unit associated with a Russian intelligence agency.

Based on the information you reviewed on the APEC Summit website, Vladimir Putin is speaking with other world leaders at the summit. This could be the motivation behind the attack. Using Sofacy malware to obtain access and steal information, such as office documents and email communication, would provide significant information on what other speakers and summit staff may want to address. The same attack group behind the phishing email would go on to target the 2016 U.S. presidential election.

Conclusion

How’s that for an analysis? You successfully analyzed a phishing email by reviewing the information in both the header and email body. You learned which fields to review and what they mean. You also identified how to assess if an email attachment is malicious and analyze various attack components used to compromise the victim system. Once you identified the file as malicious, you used Cuckoo Sandbox to find the child files created or downloaded and the infrastructure with which it communicated.

From there, you pivoted and discovered that the associated files are detected as Soficy/Sednit malware and linked these to a Russian nation-state based on open source research you conducted. Next, you learned how to enumerate attacker infrastructure through domain, hosting, and passive DNS records to find other attacker-related domains. Finally, using all the information, you extracted the indicators of compromise and created a threat profile. Together, they can be used to identify the attacker and help aid in mitigating future attacks. The specific example used in this chapter demonstrates skills you can apply to any threat investigation.

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset