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.
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:
Since the potential attack originated with a suspicious email, let’s start our analysis by examining it.
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.
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
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]
Subject: List of journalists accredited at the APEC Summit 2013
From: Media APEC Summit 2013 <[email protected]>
name="APEC Media list 2013 Part2.xls"
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
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].
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.
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
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:
remarks: Registration information: https://jprs.jp/
[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.
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.
You should always check three things in the email body:
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.
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.
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:
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 Street1:Kp rawa Roko 008/003 Bojong Rawa Lumbu
Registrant State/Province:Jawa Barat
Registrant Postal Code:17116
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
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.
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.
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.
First, using Cuckoo Sandbox, run the sample attachment. Figure 8-7 shows the “Summary” section information.
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:
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:
C:Program FilesCommon Filesmicrosoft sharedOFFICE11MSO.DLL
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 18.104.22.168 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.
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.
C:UsersAdministratorAppDataLocalMicrosoftWindowsTemporary Internet FilesContent.MSO2460C3F1.wmf
C:Program FilesInternet Explorer etidt.dll
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.
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.
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.
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.
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.
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.
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.
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.
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:
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.
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.
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 22.214.171.124, 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
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.
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
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.
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.
After doing so, you identify 14 unique IP addresses hosting the 17 identified attacker-related domains: 126.96.36.199, 188.8.131.52, 184.108.40.206, 220.127.116.11, 18.104.22.168, 22.214.171.124, 126.96.36.199, 188.8.131.52, 184.108.40.206, 220.127.116.11, 18.104.22.168, 22.214.171.124, 126.96.36.199, and 188.8.131.52.
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, 184.108.40.206, 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.
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 220.127.116.11 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 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.
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.
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 18.104.22.168, 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.
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
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
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!
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.
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.