Discover more from CTI rabbit holes, Sec and other things

Re-examining FIN4 10 Years Later

May 20, 2023

What this is:

This is an attempt to bring together (almost) every piece of public information related to FIN4 in one post and analyze it.

What this is not:

This post does not contain groundbreaking revelations about FIN4, nor it is an attempt to attribute. However, there are some new (aka probably just not publicly reported) IOCs that are presented here for historical and educational reasons.

Why this is:

The FIN4 case is extremely fascinating. While financially motivated threat groups with common and obvious motives and techniques are everywhere, groups with the probable sole purpose of obtaining insider information for better market moves are something out of a financially themed thriller. Let's say it "The Wolf of Visual Basic" :)

Later, we will refer to other cases that show that FIN4 and its motivations are not as unique as initially thought.

This post also shows how an one-person amateur team without any intrusion exposure and with very few publicly available reports, can use various free tools and open sources to research, examine, pivot, and analyze a threat group that operated 10 years ago.

High level diamond model for the FIN4 group

First reports

It was in November 2013 when Esentire

alerted about a malicious .docm file that was "circulating throughout the hedge fund ecosphere". However, as we will see later, the primary targets of this campaign were not hedge funds, at least not in its later stages, but rather pharmaceutical and biotech companies. This was one of the first public reports to show what was coming.

The macro in this malicious file opened a login dialog asking for Outlook credentials, and it also displayed a logo of the targeted company.

After the user entered their credentials, a POST request was sent to an exploited host that was being used as a C2. We will discuss more about this exploited host later on.

See Appendix 1 for Esentire's report indicators.

Nearly half a year later, in May 2014, Symantec

issued a report that was pretty similar to the previous one. It showed the same technique, where an identical login prompt was presented, and a similar POST request was sent after a successful submission. However, this time, it was sent to a different exploited host.

An example of a lure document from the Symantec report

See Appendix 2 for Symantec’s report indicators.

FireEye and FIN4

In December 2014, FireEye published an important report

on a threat group that targeted more than 100 organizations, mainly in the healthcare and pharmaceutical sector. These organizations were either publicly traded or provided advisory services such as legal counsel or investment-related services.

FireEye classified this group as FIN4 and provided a thorough analysis of how and why individuals belonging to these organizations were targeted. They also gave more details about their TTPs and a timeline of their actions.

Through their investigations into the intrusions, FireEye discovered that FIN4 had been active since mid-2013. In order to harvest Outlook credentials, the group used spear-phishing emails with attached documents containing malicious macros (similar to previous reports) or links to attacker-controlled fake Outlook Web App (OWA) login pages.

Some examples of lures from the FireEye report

The malicious actors attempted to obtain insider information about upcoming market events that could drastically impact the stock prices of pharmaceutical and healthcare companies. They accomplished this by stealing email credentials from individuals who could have access to this information, such as executives, legal counsel, and other advisors.

FireEye analysts arrived at a logical conclusion as to why these companies were being targeted for insider information theft. The reason was quite simple: pharmaceutical and healthcare companies are susceptible to significant stock price fluctuations caused by factors such as news about clinical trial results, regulations, or safety and legal issues. We will explore some examples of such companies later.

After gaining access to the stolen credentials, the actors attempted to log into the corresponding accounts via TOR. From there, they monitored and even inserted themselves into email threads that contained information that could potentially be valuable to traders, such as merger and acquisition discussions. In order to remain in these threads for as long as possible, they even changed filtering rules to block emails containing specific hacking-related words.

In terms of technical details, FireEye provided further information about the malicious macros and how the actors used target-specific keywords to identify individuals and companies. We will discuss those in more detail later. FireEye also noted that the actor initially used compromised domains for C2 operations, as previous reports had shown, and later transitioned to actor-registered domains.

One interesting observation in this report and the news surrounding it was that no malware infected the victims. However, as we will see in the next section, it is possible that the actors attempted to infect victims.

Lastly, FIN4 appeared to shut down their operations entirely in the same month that the report was released.

See Appendix 3 for FireEye's report indicators.

PWC and UpDocX

On June 24, 2015, just a day after Reuters published an article with the news

that the Securities and Exchange Commission started investigating the group, PWC released a report detailing the discovery of a malicious macro that had similar functionalities to those in previous reports but had not been publicly documented yet.

The macro had the same functionality as the macros from the previous reports, but it also downloaded a keylogger onto infected machines.

The authors of the report named the keylogger UpDocX. It was written in .NET, compiled without obfuscation, and named after the paths it used to communicate with the C2 servers.

As we will see later, there are at least three versions of the UpDocX executables available online. Interestingly, the submission dates on VirusTotal reveal that the files were first submitted before, and in some cases months before, the first public report by Esentire and over a year before the FireEye report.

We can speculate that the campaign that FireEye had exposure to did not involve any PE or they knew about them but for whatever reason they didn’t choose to publicly report them.

See Appendix 3 for PWC’s report indicators.

Pivoting, enriching & code analysis

Searching for intrusions that happened 10 years ago in publicly available sources was easier than initially expected. After 10 years, there is a lot of accumulated free and open information available in various tools. However, a decade is still a significant amount of time.

Before we dive into this section, it's better to provide a link (although it is not necessary to click on it) to a GitHub repository

that contains some research byproducts in the form of a Maltego graph and Vertex Synapse nodes. These byproducts will provide additional context for anyone who needs them, as we focus on a subset of the most critical pivoting steps here. Additionally, the appendix also contains some of the IOCs that were not included in any of the public reports.

The techniques presented here are the result of the optimized trial and error work that was conducted while researching this article. And most of the time, we accept the assumption that the information provided from various generally trustworthy sources, such as DNS-related records, are mostly accurate.

We will begin our pivoting and enriching journey with the most "pivotable" and valuable IOCs, which can be found in the FireEye and PWC reports. While exploited legitimate hosts, from the earliest reports, can have a defensive value, actor-registered domains or hashes from actor-created files provide a more valuable and pivotable area.

With that said, the FireEye's 9 actor-registered domains that we saw earlier and the PWC's provided MD5 hash d102693540b53f9a564e3a550f938709 for the sample that could download the keylogger, are sufficient to expand our findings slowly and methodically into this

First, we will try to pivot from the FireEye domains.

To accomplish this, we will utilize a very simple custom synapse powerup

. This tool will allow us to easily print potential pivoting sources depending on the type of the IOC (synapse node).

Below, we can see an example of potential pivoting sources for the msoutexchange[.]us domain:

A side note: I should say that in this post, I will also provide examples of the use of Synapse

. Specifically, I will give some examples from a self-hosted open-source CLI version

. As an amateur, I found the open-source version sufficient and I was pretty happy with the results. However, if you are a professional analyst, you should really consider the licensed graphical user interface. It has many more features, capabilities and you can be much more productive than the CLI version. I am not affiliated in any way with the folks from Synapse.

It would be wise to check as many of these sources as possible, if not all of them. Over time, more experienced users can prioritize the most valuable sources. For the purposes of this article, we will focus on sources that have proven to be useful for this specific research.

For example, in order to obtain more information related to passive DNS and WHOIS data, such as hosting provider information, dates of DNS resolutions, and name servers, the following sources were invaluable:

DNS history from completedns

Here, we can see domain-related changes arranged chronologically, allowing us to answer questions such as:

What was the domain status in the months prior to the FireEye report, and when was it first registered?
Which name servers were used?
Were there any changes to the name servers?
When was the domain dropped?
Was the domain sinkholed after it was dropped?

We can see that prior to the release of the FireEye report, the domain was registered around June 18, 2014, with nameservers originating from domains4bitcoins[.]com. After a few days, the nameservers were subsequently changed to bitcoin-dns[.]com, and then to lovingdomains[.]com.

DNS history from securitytrails

Here, we can answer similar, if not the same, questions as the completedns source. Additionally, we can gain some glimpse into the DNS resolutions of the domains to their respective IPs and into DNS records that are not simple A records (e.g. MX records etc)

Although there is always some overlap between the sources, it is only through their combined use that we can cross-check the information and obtain a more complete picture.

WHOIS history from IntelligenceX

As we will see later, WHOIS data has proven to be very useful in finding some actors' human fingerprints.

Records were found for almost all the domains provided by the FireEye report. Using the email oscarwalsh72@mail2tor[.]com that registered the domain outlookexchange[.]net, another domain was discovered that wasn't previously publicly known, webaccesslogin[.]com .

No DNS A records were found related to this domain using the sources we discussed previously, as it was probably quickly dropped.

Malware related information connected to this domain through VirusTotal

Using VirusTotal is almost always necessary to helps us identify connections to malware, among other things. Unfortunately, in this particular case, the free tier of VirusTotal didn't provide much value, but I decided to talk about it because the value of this source is immeasurable most of the time.

Connections with other indicators with AlienVault OTX

Using AlienVault OTX (Open Threat Exchange) has provided us with some interesting subdomains and URL paths, along with their respective dates of appearance.

Furthermore, we can explore related pulses (aka collections of indicators) where this domain appears

We repeat this step for every domain and record the results in the relevant synapse nodes and/or Maltego for easy querying and visualization

Continuing the pivoting, now with the MD5 hash d102693540b53f9a564e3a550f938709 provided by the PWC report, we'll use the same Synapse power-up.

A sample of this MD5 can be found on vx-underground.org

To extract the VBA code, we'll open a REMnux VM

, move the sample there and run the command pcode2code d102693540b53f9a564e3a550f938709 on the extracted sample.

A valuable source in this case proved again to be the AllienVault platform

. Within the related pulses, we quickly found one pulse that references the PWC report and contains more indicators than the report itself

Among them are some additional hashes that we can use to search for some UpDocX downloadable samples through VirusShare

After obtaining the samples, we use the REMnux VM again to extract the C# code using the following command:

ilspycmd 38fbbd70ea14e78d44b9b841a4bccd65c7051c7cb59b28c186c16e964399845a

Three different versions of UpDocX samples were found. By comparing the differences between the versions, we can potentially gain some insight into the reasons behind the changes. A small part of the code differences is shown in the following screenshots.

Some of the changes between the build version 1.0.0 and 1.0.1:

Some of the changes between the build version 1.0.1 and 1.0.2:

For example, we can observe C2 changes and some url manipulation. I do not have any idea for the reason behind the additional slashes. Is that a common tool behavior or a lazy attempt to hinder defensive solutions that use simple regexes? For instance, Nginx typically merges multiple slashes by default, and theoretically, the request would function the same way with one or three slashes. Please feel free to comment on this, as I didn’t find many examples of this tactic while searching.

From here, and after getting a glimpse of the developer choices throughout the available code evolution, we can further study and analyze the code of UpDocX and the macro samples.

Among other things, we can observe the macro's credential-stealing functionality,

the keylogger in UpDocX,

and the cleaning capabilities of the UpDocX sample.

Human fingerprints

Inspired by the paper "Exploring the Human Fingerprints on Malware" by Tobias Johansson and Robert M. Lee

, I tried to expand on its lessons and aim to discover some patterns-themes that arise from specific adversary choices. Regardless of whether it is directly related to malware or not.

Although the study of the malicious code itself didn’t result in many unique, to the adversary, patterns, the WHOIS records reveal some clear patterns and choices. WHOIS records that the public reports don't provide any information about them.

By using the public sources we saw earlier, 9 WHOIS records were found related to the known actor-registered domains.

9 actor-registerent domains from the FireEye report + 1 from pivoting. The query seems a bit complicated, but: 1) I wanted to query the data in the exact way I wanted it to appear in the screenshot; 2) I wanted to demonstrate how flexible it can be when you use a whole new language to query data, and 3) The licensed GUI makes things much simpler than the CLI :)

In these 9 WHOIS records, we can see some interesting patterns in the registrant contact details:

WHOIS emails:
Except for the email outlookmountain68@safe-mail.net, which was used to register the outlookscansafe.net domain, we can see a consistent pattern in the format
[registrant name][registrant surname][0-9][0-9]@[mail2tor.com]
This reliance on the Tor network aligns with the reported usage of Tor by the threat actor when accessing the hijacked emails.
WHOIS registrants location details:
Upon examining the location details of the registrant contact information, we can see a clear trend of copying and using public location details, almost exclusively, from hotels.
Some examples:

As for the code itself, we can get into many rabbit holes, but nothing seems to stand out as very unique to the adversary.

However, and because of the PWC analysts’ hypothesis that maybe some of the developers spoke french, made me wonder, if the naming convention of a specific class and its method were rooted(?) in french words (French-speaking people, please feel free to comment on that).

Those are the class named Enloggment

and the method named Logment

From a developer perspective, this choice stands out from the rest of the code, which appears to use common English words and programmatic naming conventions.

Of course, that can mean a lot of things or nothing at all, and we can't get inside the adversary's mind, but it seems a bit unlikely that this choice is random or copied from public code sources. More on this choice of names later, when we talk about attribution, because as we said there is a somewhat high probability that this is the code snippet that PWC based its conclusion that maybe there are some french speaking developers behind this actor.

These "Human Fingerprints", aka patterns, aka human choices, could potentially reveal connections to other intrusions. While not at all indicative, it could be proven useful in the right context.

Closing this section, let's try something new. A "digital centaur"

(aka a hybrid of tech and AI with human intellect) of an intelligence analyst was always a very fascinating topic for me and offers plenty of ideas for future projects. So I tried the French words hypothesis with GPT-4 in order to get a glimpse of the future. That said and before showing the fun example, it is very important to say that the current results must be 100% filtered through human analysis, but at least, when you don't have a team and for brainstorming or other structured analytic techniques, this is great.

This is the future , and not much will change that.

Just before posting this, I tried making a personal threat intelligence chatbot. I spent a weekend using the ideas from this repository (https://github.com/mpaepper/content-chatbot) and applied them to all the reports stored at https://orkl.eu/ transforming them into embeddings. The results were fun but mixed, showing that there is plenty of room for tweaking and experimenting to achieve better answers.

Here is a fun example:

Again, the future is here…

Victims & Targets

Before we proceed, it's important to note that the organizations mentioned below have either been publicly referenced in reports, in publicly available tools, or in IOCs lists, or they no longer exist (e.g., they were acquired or merged). In some examples mentioned below, it's unclear which organization the names found in the code actually refer to. And let's be clear that there is no evidence or a way to determine if any of these organizations had their client-related data accessed or exfiltrated.

With that said, we can divide these organizations into two categories: exploited-victims and targets. In this context, victims refer to organizations that have been compromised along the way to achieve the ultimate goal of compromising a target. In some cases, a victim can easily transition into the "targets" category as they are exactly the organization that FIN4 would like to compromise in the end.

Exploited organizations - victims:

Within the 3 publicly available UpDocX and 2 VBA samples, these 4 second level domains could be found:

cooperstandard(.com)
advantarlabs(.com)
palmettogoodwill(.org)
intermune(.com|.se|.ca)

Two of them stand out as biotech companies: Intermune and Advantarlabs, both acquired or merged in 2014 and 2016, respectively.

Intermune is the most interesting as its name not only appeared in similar cases, as we will see later, but it was also acquired during the active period of FIN4. Again, without exposure into any intrusion, it would be unwise to conclude that this organization was specifically targeted and it wasn't just a vulnerable victim.

We initially saw Intermune related indicators in the Esentire report. Additionally, the intermune[.]se domain was used as a Command and Control (C2) in three publicly available samples.

Two of these samples were UpDocX samples

that were first submitted to VirusTotal in 2013 when FIN4 made its first appearances. The third sample was a macro that

originally sourced from here and is a version that doesn't download the keylogger.

The interesting thing that makes us wonder whether Intermune was simply a victim or a target is the fact that Intermune was a biotech company that was eventually acquired in August 2014

, just a few months before the report from FireEye, which likely led to the group ceasing operations. It should be said also that FireEye observed that FIN4 didn't seem to use exploited domains in the last months before the report, and there is a high probability that the first Intermune intrusions were dealt with, long before the acquisition.

With that said, we can take a look at how the stock price can fluctuate in response to news of an acquisition or merger

The cherry on top is that in 2016, it was announced that the company was also targeted by Chinese hackers through the hacking of two law firms, which held information useful to insider trading

There's no way to know if those defendants had any involvement with FIN4. It's unlikely. One of the PwC report's authors also raised the same question

The indictment mentions activity that continued until 2015, which might explain the discrepancies in the dates. FIN4 wasn't the only group with this idea, and those particular Chinese hackers didn't solely focus on biotech and pharmaceutical organizations through those law firms.

Targets:

Details for at least two organizations can be found, that maybe fall under the “targets” category.

FIN4 used codes in their macros to recognize the origin of the stolen credentials

One example can be found in one of the macro samples,

but it is unclear which specific organization this name belongs to, since many companies are called AMG. Even if we filter the relevant organizations based on targeted sectors, I think it is unwise to conclude that a company was targeted just because three letters were found in the code, without any additional evidence.

The second example is a bit more clear. This company underwent a merger in April 2016, but it is highly probable that it was targeted in 2013. In this particular case, it was not something found within the samples, but rather a logo in a screenshot from the Symantec report:

This prompted me to try and make a reverse image search to see if it was a real screenshot with a logo from a legitimate organization.

Google and Bing reverse image search weren't very helpful but the yandex one was.

Surrounded by dozens of similar logos in the search results and after trying different search operators, something caught my attention:

Now, let's examine another example of stock fluctuations and see how the Synta Pharmaceuticals stock performed following its merger with another pharmaceutical company in April 2016

I will close with a farfetched hypothesis, because it is simply interesting. While researching some of the exploited-victim domains, I stumbled upon some leaks, specifically the LinkedIn breach of 2012 and the Adobe breach of 2013. One hypothesis that we can consider, and attempt to disprove, is that these intrusions on the victims (not the targeting itself) may have provided the initial foothold. This is because almost all, if not all, of the exploited domains had email and password combinations (hashed or plaintext) that were exposed in those breaches. One could argue, and rightfully so, that there were millions of records in each breach, so it could be merely a coincidence and I agree with this perspective.

Nevertheless, all hypotheses can be valuable in the broader context as long as we avoid fallacies.

Musings on "attribution"

In hindsight, it's a bit naive to draw any meaningful conclusions without sufficient exposure to the intrusions. However, it's still a fun exercise to discuss the hypotheses presented by expert analysts without trying to attribute the attacks myself.

Two attempts have been made to identify the actors of these attacks.

One hypothesis comes from the FireEye report and from FireEye representatives

, which suggests that the attackers may be from Europe or the United States, based on their native level of English usage and their deep knowledge of financial markets. While this context adds meaning and value to the FireEye hypothesis, it would be helpful if the analysts could provide a clearer level of confidence and more examples of the actors' linguistic capabilities. For example, it would be interesting to see how they differentiate a person who speaks in a native level and who is not from an English speaking or western country from one that is. And specifically in this case, Where there any geographic influences and idiosyncrasies for example?

But we could agree, that the value that is being added to the context, from the deep knowledge that the actors had of western financial markets and the inner workings of the companies targeted, make this hypothesis more possible.

The other attempt was made by PWC analysts, who examined the new found UpDocX samples and believed that a French-speaking developer may be among the authors of this specific malware, based on naming conventions.

It would be helpful here also, to know more about the specific French naming conventions and the level of confidence.

If and only if, we accept that the french naming conventions were the Enloggment class and the Logment method, then they do not appear at first glance, to be a random choice (as we talked previously in the "Human Fingerprints" section).

However, because this actor possibly copy-pastes code snippets directly from the web, it raises some doubts about the originality of their naming conventions.

For instance, there is an old public forum thread from several months before the first samples appeared. In that thread, someone asked for a method to identify a Windows version using VBA. In response, another user shared a code snippet for everyone to use. Interestingly, this code snippet is nearly identical to the one found in the macro samples, with the main differences being in the whitespace. (For the privacy of those users, I won't post anything here.)

That being said, it's not uncommon for developers to have bad habits like copying and pasting code from the web, whether it's from french-speaking coders or not, without making any changes. Even if the developers in this group, for the most part, seem to be at least “OK”.

Finally, there are two things that I couldn't find much public information about.

Crowdstrike called this group "Wolf Spider," but there doesn't seem to be any other meaningful public information available about them. It would be really helpful to know what Crowdstrike has to say about this group.
The MISP Galaxy project identified the group's location as Romania, which was really interesting, but I couldn't find anything in public about this.

If anyone has any additional information on these topics that can be shared, please feel free to reach out to me.

Similar cases

Before closing this article, let's explore some interesting similar cases that exist involving hacking and "insider" trading.

These cases are not mentioned here because they have any connections to FIN4, but they are still intriguing and contribute to a more complete picture.

In October 2007

, the Securities and Exchange Commission (SEC) alleged that an Ukrainian by the name Oleksandr Dorozhko, hacked into IMS Health Holdings and stole earnings-related information in order to gain a trading advantage. In 2010, Dorozhko lost the case.

In August 2015

, the Department of Justice charged 9 people who, for five years were accessing, no publicly issued yet, press releases, through the hacking of companies that specialized in the distribution of press releases from major publicly traded companies.

In December 2016

, an IT professional charged by the SEC for allegedly hacking executives of the online travel company Expedia and trading based on exfiltrated company secrets.

Same month again and in December 2016

, 3 Chinese traders-hackers charged by the SEC for compromising two New York based Law firms by installing malware and exfiltrating emails and confidential market moving information. This is the case we saw earlier when we talked about Intermune.

Kind of ironic but in January 2019

nine people were charged by the SEC for hacking the SEC... And more specifically the SEC's Electronic Data Gathering, Analysis, and Retrieval (EDGAR) system, extracting no publicly available financial information. And if that wasn't enough, this case had a similar defendant as the case of August 2015 discussed a bit earlier.

Lastly, in December 2021

, five Russians were charged by the SEC for hacking two firms that assist publicly traded companies with the preparation and filing periodic and other reports with the SEC. One of them, a former member of the GRU, was also charged with meddling with the 2016 US elections.

Epilogue

This concludes the research. If you would like to learn more, please check out the GitHub repository which contains the Maltego and Synapse files, some YARA rules, and sample code.

I tried to keep the speculations to a minimum to avoid getting lost in unnecessary rabbit holes. It would be interesting to learn one day the identity of the group behind this, but at the end of the day, it doesn't matter. Perhaps the real treasure were the TTPs we learned along the way :)

If you have any additional information about this adversary or notice any mistakes, errors, or inaccuracies in the research above, please let me know. I would be happy to update this article accordingly.

Thanks for reading

Appendix

Following are all the IOCs provided by every third-party public report or discovered during the research for this article.

After so many years, these IOCs no longer hold any significant value for defensive purposes and they are presented here for historical and educational purposes.

1. Esentire IOCs

| Domain | www.intermune[.]com |
| Domain | www.intermune[.]se |
| Domain | www.intermune[.]ca |
| IPv4 | 64.79.124[.]20 |
| URL | http[:]//www.intermune[.]com/media_library/reporter.php?msg=MACRO_EXECUTED_WORD_CLIENTNAME_P_ONLY&uname=NULL&pword=NULL |

2. Symantec IOCs

| Domain | www.palmettogoodwill[.]org |
| URL | http[:]//www.palmettogoodwill[.]org/files/report[REMOVED]MACRO_EXECUTED_WORD_SYNTA_PHARMA_P_ONLY&uname=NULL&pword=NULL  |

3. FireEye IOCs

| Domain | ellismikepage[.]info |
| Domain | lifehealthsanfrancisco2015[.]com |
| Domain | rpgallerynow[.]info |
| Domain | dmforever[.]biz |
| Domain | msoutexchange[.]us |
| Domain | junomaat81[.]us |
| Domain | outlookscansafe[.]net |
| Domain | nickgoodsite.co[.]uk |
| Domain | outlookexchange[.]net |
| URL | http[:]//www.junomaat81[.]us/report.php?msg=FAKE_PHARMA&uname=john.doe&pword=abc123 |

4. PWC IOCs

| Domain | advantarlabs.com |	
| URL | http[:]//www.advantarlabs[.]com/plugins/extension-xtd/WINWORD32.exe | 
| MD5 | d102693540b53f9a564e3a550f938709 (Macro)|

5. Discovered IOCs

These IOCs are related to the pivoting, enriching, and code analysis section of this article and have not been presented in any of the 4 public reports.

| Domain | webaccesslogin[.]com |
| SHA256 | ab385c7bcb2ad420ffe04d34705ca3e94981f80d7d0c95fb26241e4857aa8a9a (Macro) |
| SHA256 | 38fbbd70ea14e78d44b9b841a4bccd65c7051c7cb59b28c186c16e964399845a (UpDocX) |
| SHA256 | 0cdc56f7e006999cf53d3b23dba7687de0368e0548a020df09a2df6e0ed0ced4 (Macro) |
| SHA256 | d22df444e867fdf647f6757547b2b75968453c3bb398a5d94c5e17a5e57af7f6 (UpDocX) |
| SHA256 | 629e8270c623002157cb38fe0f612665f22094cdc479c36452ee8fdc5d73326b (Updocx) |
| SHA256 | 390536f45d1193e9e1f99073b2cf05974a7f8bdbd06bc093cdfc9b421392bb09 (Macro) |
| Email | oscarwalsh72@mail2tor[.]com (WHOIS) |
| Email | davemilton78@mail2tor[.]com (WHOIS) |
| Email | robertprice83@mail2tor[.]com (WHOIS) |
| Email | outlookmountain68@safe-mail[.]net (WHOIS) |
| Email | michaelellis90@mail2tor[.]com (WHOIS) |
| Email | junomaat81@mail2tor[.]com (WHOIS) |

https://web.archive.org/web/20141208134752/https://www.esentire.com/wp-content/uploads/2013/11/esentire_alert_20131108_DOCM.pdf

https://web.archive.org/web/20151031072501/http://www.symantec.com/security_response/writeup.jsp?docid=2014-052813-3721-99&tabid=2

https://www2.fireeye.com/rs/fireye/images/rpt-fin4.pdf

https://pub-7cb8ac806c1b4c4383e585c474a24719.r2.dev/f47efbaa0ca27a61c1eb8801e50393ff2fc991a5.pdf

https://www.reuters.com/article/us-hackers-insidertrading-idUSKBN0P31M720150623

https://web.archive.org/web/20170226084058/https://pwc.blogs.com/cyber_security_updates/2015/06/unfin4ished-business.html

https://github.com/stvrsxz/research/tree/main/fin4

https://github.com/stvrsxz/synapse-lctih

https://vertex.link/

https://github.com/vertexproject/synapse

https://completedns.com/dns-history/

https://securitytrails.com/domain/msoutexchange.us/history/a