Threat Research

Cookie Maker: Inside the Google Docs Malicious Network

By Artem Semenchenko | November 21, 2018

FortiGuard Labs recently discovered a running Google Docs malware campaign that uses the names of Fortinet and FortiGuard. When we examined the documents, we encountered a long chain of redirects inside a malicious network, and the destination of this chain was dependent on our IP and the user-agent that was used. This malicious network targets all major platforms: Windows, Android, and MacOS.

In this article we analyze this malicious traffic workflow, as well as samples targeting the Windows platform. At the end of the article, we also analyze the attribution information to try and determine who is behind these attacks.

Malicious Documents

In the summer of 2018 it was discovered that Google documents with an access policy based on a specific link can be inadvertently indexed by search robots if those robots become aware of such links. As a result, the internal documents of a number of organizations became public. In one case, a document containing a summary of hiring policies in a Russian bank caught the attention of human rights activists. Among other things, it documented a policy prohibiting the hiring of certain groups of people based on their religion or sexual orientation.

There were also a lot of documents revealed that contained passwords in clear text. The problem was made worse because these documents could easily be found by using the key word “password” in the Google Documents domain. Now, before you rush to delve into other people's secrets, you might want to wait--at least until you finish reading this article. J Things aren’t always what they seem.

When the FortiGuard Labs team heard of this issue, we conducted a search just to see if any of Fortinet’s internal documents had been exposed. They were not. The only thing we discovered were the default passwords for Fortinet devices (these are the same passwords provided in our documentation, which are not secret).

Nevertheless, our search was not in vain because we also found something interesting. Here are the search results for the keyword “Fortiguard”:

Figure 1: Google search results for the keyword “Fortiguard”

168 results were found by Google in that search. (Interesting observation: the number of results produced by a Google search actually varies based on the country to which your IP belongs.) Among the 168 results just cited, more than 150 actually (more than 90%!) led to documents crafted by criminal actors. (So much for hurrying to look at “private” documents!)

About another 750 malicious results were found by searching with the keyword “Fortinet”. You can find links to some of the documents we discovered listed in the appendix. The reason this is a shorter list than what was mentioned is due to the fact that multiple search results led to the same documents. As we investigate this further you will understand how criminal actors managed to achieve these results.

Moreover, Fortinet’s situation is not unique. We learned that if we Googled the name of any major player in the cybersecurity market that we would stumble upon a hundred or more malicious documents. That’s when we realized that we are dealing with a campaign that includes thousands of malicious documents that have been inserted all over Google Docs.

Malicious Documents Analysis

We analyzed a number of these malicious documents and concluded that they were written in different languages, though primarily in English and Russian. Despite language differences, these documents all have a common structure. There is a large header, then a small random screenshot not necessarily related to the header, and then a hyperlink that is also written in a large font. In the figure below, you can see several examples of such documents. 

Figure 2: Several links to malicious documents

Below the hyperlink there is a lot of empty space that was specifically inserted to hide “rubbish text” inserted at the bottom of the document. However, this “rubbish text” serves the purpose of luring a Google crawler into indexing the document using the variety of different keywords the text includes. This explains why so many Google results lead to the much fewer final number of actual Google documents, because multiple links direct a user to the same document. 

Figure 3: A portion of the "rubbish text" in one of the malicious documents

Analysis of Malicious Links

If a victim clicks the hyperlink in the malicious document, a chain of redirects occurs. The destination is chosen based on the user-agent field of the “GET” request, as well as country of the victim's IP.

Redirection Chain

In this section we analyze the redirection chains generated by clicking the hyperlink of the document with the header “Fortiguard web filtering bypass software free download”. This document is shown in the upper left corner of the Figure 2. These results are similar to the links found on any of the documents.

First, we’ll list the overview redirection chain for Singapore’s VPN IP (our location) and the User-Agent corresponding to Google Chrome (our browser):

  1. hxxp://vbtrst[.]pro/dnew?k=Fortiguard+web+filtering+bypass+software+free+download
  2. hxxp://sxkwor[.]space/rtb/s/APEN2FuhOAAA4dsBAFNHGQASAGmZEJMA
  3. hxxp://11fileupload-2[.]xyz/it…fA==
  4. hxxp://static.[.]de/file?f=ae…05&utm_source=APEN2FuhOAAA4dsBAFNHGQASAGmZEJMA&utm_medium=14497&utm_campaign=default
  5. hxxps://thimbleprojects[.]org/dedzsumkoi/528138/?method=blob&type=download&name=Rm9ydGlndWFyZF93ZWJfZmlsdGVyaW5nX2J5cGFzc19zb2Z0d2FyZV9mcmVlX2Rvd24ucmFy&v=
  6. hxxps://4requests[.]org/findic.php?v=eyJ0cmFuc2FjdGlvbl9pZCI6IjU0ODAyMjI1NiIsInRva2VuIjoiOWM0MDVmOTIwYTdhYTI2ODE0MzdkMjRkZGRhNTM2YTUifQ=="

Next, let’s analyze the unusual parameters used in each of these URLs:

  1. hxxp://vbtrst[.]pro/dnew?k=Fortiguard+web+filtering+bypass+software+free+download
    The purpose of this first link’s parameter is obvious – it simply repeats the header of the document.
  2. hxxp://sxkwor[.]space/rtb/s/APEN2FuhOAAA4dsBAFNHGQASAGmZEJMA
    The parameter of the second URL is a BASE64 encoded set of bytes.
  • The first six bytes of the set is an UNIX Epoch timestamp in Little-endian byte order, shown in green on the picture below. 
  • The next two bytes are “utm_medium number” in little-endian byte order, shown in yellow.
    We’ll show you how this field is used later on in this analysis.
  • The thirteenth and fourteenth bytes (0-based count), shown in red, are a country code in ASCII encoding (big-endian byte order this time). When we tried different IPs we got different results for this field. Two different cases for Russian and Singapore IPs are depicted below.
Figure 4: Decoded parameter for a Singapore IP (left) and a Russian IP (right)
  1. hxxp://11fileupload-2[.]xyz/ it…fA==
    The next parameter is another BASE64 encoded string with an additional level of encryption. We shortened it here for the sake of compactness.
  2. hxxp://static.[.]de/file?f=ae…05&utm_source=APEN2FuhOAAA4dsBAFNHGQASAGmZEJMA&utm_medium=14497&utm_campaign=default
    Here we see the same Base64 encoded parameter as used in step #2. Besides that, the number 14497 is transferred as a value of the utm_medium parameter. The number 14497 corresponds to 0x38A1 in the hexadecimal numeral system, or 0xA1 0x38 in little-endian byte order. Inrterestingly , this is the same number as shown in the yellow rectangle in Figure 4.
  3. hxxps://thimbleprojects[.]org/dedzsumkoi/528138/?...
    For this URL the criminal coders abused Mozilla’s online code editor. We can still discover the meaningful names of the parameters as well as their BASE64 encoded values. Here is the parameter’s part of the URL after decoding:

    As you can see, we have found the name of our document once again, but this time with a .RAR extension.
    At this point, the appearance of the document name looks like a little magic trick. How is it possible that we have the name, which is at least 54 bytes long, if on step #2 we see the transfer of a parameter that is only 24 bytes long and there was no Referrer field used to track previously visited URLs? Moreover, as we recently found out, most of these bytes are related to the timestamp or victim’s IP, and therefore cannot be related to the document name.
    One possible explanation is that the actors who runs vbtrst[.]pro, and the actors who abused, are actually the same group of people. That would make it possible to maintain a shared database where the names of all documents corresponds to certain numbers. Using this logic, it would be enough to simply transfer only a few bytes of information (a number in the database record) to restore the full name of the initial document. Further, it seems quite possible that the utm_medium field is actually being used for this very purpose.
  4. hxxps://4requests[.]org/findic.php?v=eyJ0cmFuc2FjdGlvbl9pZCI6IjU0ODAyMjI1NiIsInRva2VuIjoiOWM0MDVmOTIwYTdhYTI2ODE0MzdkMjRkZGRhNTM2YTUifQ =="
    This is the same parameter as used on the previous step (it corresponds to {"transaction_id":"548022256","token":"9c405f920a7aa2681437d24ddda536a5"})
As you might have guessed, the following file was downloaded as a result of the redirection chain:


Inside the archive there was also a malicious PE file, which we will discuss in the Windows Samples Analysis section.

Dependency on the User-Agent field

As was mentioned earlier, the redirection chain is heavily dependent on the User-Agent field of the victim (we will use the abbreviation “UA” from here on for brevity). 

Internet Explorer

When we used the UA corresponding to IE11, we got the next chain of domains used:

Vbtrst[.]pro -> sxkwor[.]space -> 11fileupload-2[.]xyz -> static.[.]de

Yes, this chain looks very similar to the previous-one, except it was shortened. Here, the static.[.]de gives away malicious samples without additional “hops” to the and 4requests[.]org. Our guess is that these additional redirections are used in an attempt to protect static.[.]de from being blacklisted by the Google Safe Browsing technology. 

Mobile devices and Safari (Macintosh)

When we used UAs corresponding to mobile devices or MacOS, we got two new chains of redirects. In the end of each chain, we got corresponding .APK or .DMG file. These files will be discussed in the separate chapter of this investigation.

Analysis of the Windows Samples

During our tests using different IPs and User-Agent fields, we obtained a dozen different samples, all of them targeting the Windows platform. In this section, we will discuss the tricks used by these criminals in an attempt to avoid detection by antivirus vendors.

Changeable Internal Structures

Although all studied samples share the same behaviors, they have a wide variety of different – and sometimes contradictory – internal structures. For example, one of the samples has the FileDescription field specified as “MODJO Internet Security”. Interestingly, this same sample also has a manifest where the description field is already specified as “Installs Adobe Flash Player”. 

Figure 5: Description fields contradiction

To make things even more complicated, the same sample uses an icon that is very similar to the logo of the – a popular social network in Russian speaking countries.

Figure 6: The icon of the malicious sample (left) and the logo of the social network (right)

Regarding the name “MODJO Internet Security” – we noticed that the last letter is changed from time to time. We were able to find the samples with following names:

                MODJO Internet Security

                MODJA Internet Security

                MODJB Internet Security

Another point of difference between the samples is the .RSRC section. Diversity is achieved through the use of various .png images packed inside. The number and size of these images differs significantly from sample to sample, although none of these images are ever shown to the victim.

Figure 7: PNG files, packed into the .RSRC sections of two different samples

So, why the samples different and inconsistent in so many ways? We cannot answer this question for sure, but our guess is that all parts of the samples are chaotically changed to avoid probable detection.

Behaviour Analysis

Although the samples have different internal structures, their behaviour is exactly the same. The communication between a malicious sample and its C2 server is shown on the figure below. We can see that the sample is sending a POST request to the C2 server. The C2 is also located on hosting, like one of the redirection nodes we studied earlier. But, the C2 and redirection nodes uses different IPs.

The key shown on the figure:

Figure 8: A malicious sample's network requests

The key shown on the figure was the same for every Windows sample studied, though that may depend on the original Google Document.

Upon receiving a response from the server, the sample tries to download and execute the web-installer of a legitimate third-party application GetGo Download Manager. Upon successful execution (or after several failed attempts), the sample then deletes itself.

We think that the purpose of the criminals who designed this was to abuse the referral programs of legitimate applications. When a referral program is involved, some sort of referral field is usually used to distinguish one referral from another. However, this is not the case in this instance: the request does not use a referral field, nor is the accessed URL any different from the URL a user obtains from the main Getgosoft page.

A distinctive feature of this query is the User-Agent field used:

                User-Agent: Medunja Solodunnja 6.0.0

Please take a note of the name used: we will come back to it later.

Figure 9: The request generated by the malicious sample

Compilation and Signing “On The Fly”

Another distinctive feature of this malicious campaign is that samples are compiled and signed “on the fly.” We compared the TimeStamp field inside the PE header of the samples and the actual time of the download. The difference between the two was not to exceed 5 minutes. Moreover, every sample is signed by the same valid digital signature at the moment it was downloaded.

We analyzed the certificates used to generate signatures and all of them were issued by the COMODO RSA Code Signing CA. Here are the certificates we encountered during our investigation:


00 ce fe 4e ae e4 c0 cf 51 e9 5b 30 cf 02 80 b7 94                RICK, SKY LIMITED


‎                00 b1 ab f8 ab e0 ab 1f c2 36 ed be 9f fc 4f 66 cb                UR-IN, LIMITED


‎                00 9b ea 5b a5 5f 1b 91 61 c1 be 05 93 00 3b 3f a1            MIR CORPORATION – LIMITED


We do not know how these criminals obtained these certificates. However, the names of the organizations look rather strange: they contain commas and dashes in the middle of the string. We would not be surprised if these certificates were not stolen, but rather, registered by the criminals right from the beginning. If that was the case, then it raises questions about what verification process is currently being used by Certification Authorities to ensure that a certificate requester is a legitimate company.

Signing Time’s Mystery

When we analysed the samples from this malware campaign, we also spotted some interesting results produced by Microsoft’s popular tool Sigcheck. For some reason, the samples discussed in this article utility (up to the latest 2.7 version) report the current system time instead of the signing time.

The same strange results were reported by the popular service VirusTotal. For example, on the picture below you can see that the last analysis of the sample was at 2018-11-14 14:05:19 GMT, but according to VT it was signed on 2018-11-14 15:05:00 (one hour ahead of the actual GMT time 😊)

Figure 10: Sigcheck (left) and VirusTotal (right) results for the sample SHA256:b84d9c08fc35c3a160b4ee1f4061035a4bb9781e5f64e623ec988b8447b2c667

FortiGuard labs reported the found bugs to the VirusTotal and Sysinternals teams. Mark Russinovich is already preparing a new version of the Sigcheck. VirusTotal confirms that they rely on the Sigcheck utility analysis when processing samples in their system and they are currently awaiting a new version of Sigcheck.

Who Is Behind These Attacks?

Let’s summarize some facts that we uncovered about these attackers during our analysis:

  • The two most popular languages of the malicious documents are: English and Russian. If you look closely at Figure 3, you may notice the use of the Russian language in the second line from the top.
  • The project name used by the criminals to abuse thimbleprojects[.]org is dedzsumkoi.
    Dedzsumkoi is a transliteration of the Russian word “Дед с сумкой”. This literally translates to: “Grandfather with a bag”.
  • The criminals used the logo of – a popular social network in the Russian speaking countries.
  • The User-Agent used by the criminals is “Medunja Solodunnja 6.0.0”
    Medunja Solodunnja is a transliteration of the Russian words “Медуня-солодуня”, which is a local cookie maker located near Lviv Ukraine
Figure 11: Медуня-солодуня location near Lviv Ukraine

Summing up, we conclude that the criminals involved in this project are fluent in Russian, and they are possibly familiar the local cookie maker located near Lviv Ukraine, which gives us a strong possibility for their location.

When we analyzed the registration data for the domains used by the attackers, we found that almost all of the domain registration data is protected by services like WhoisGuard. The domain 4requests[.]org is no exception - currently all its registration data is hidden. But when we checked the whois history for this domain, we found that it was initially registered for an address … in Lviv Ukraine.

Figure 12: Whois history record for 4requests[.]org

We cannot verify that the provided registrant data is not fake, but it does align with our other findings quite well. We checked the other domains registered under email egonow999[@] and found 321 of them. Most of these domains were registered recently, and their names do not look as if they are intended to be used for any legitimate activity. 

Figure 13: Domains registered with the email egonow999[@]


FortiGuard Labs discovered a massive malicious Google Docs campaign which includes hundreds of malicious documents. Every malicious document leads to q chain of redirects based on victim’s User-Agent and IP.

We analyzed many of the redirection chains used inside this malicious network, as well as downloaded several samples. We concluded that the current goal of this network is to abuse the partner programs of other applications. However, this objective can be easily changed at any moment.

In addition, we analyzed the attribution details and got some ideas as to who might be behind these attacks, or at least, where these attacks might be originating from.

Android and MacOS samples will be discussed in upcoming articles. FortiGuard Labs will continue to monitor newly registered domains for malicious activity.


FortiGuard Web Filter blocks all of the discussed URLs and domains as malicious.

All discussed samples are detected with the following AV signature name:


Malicious User-Agent requests are blocked with the following IPS rule:


-=FortiGuard Lion Team=-


Certificates used by the criminals (all issued by COMODO RSA Code Signing CA):


00 ce fe 4e ae e4 c0 cf 51 e9 5b 30 cf 02 80 b7 94               RICK, SKY LIMITED


‎00 b1 ab f8 ab e0 ab 1f c2 36 ed be 9f fc 4f 66 cb                                UR-IN, LIMITED


‎00 9b ea 5b a5 5f 1b 91 61 c1 be 05 93 00 3b 3f a1            MIR CORPORATION – LIMITED




05cfdf3f05a41a711991f819fcbc56b05172be9ea3d2c5750d5fd42e73eb1403 - W32/Kryptik.GLKH!tr


0a0b7edd15995bb5cb59f3a10d5b24f1ca4e5091aff31200cee637fcddaf2316 - W32/Kryptik.GLKH!tr


19b8e784cd8306d55d8281675215f4343daa6cc50b72d7a449ee7fab7de5252c - W32/Kryptik.GLKH!tr


23f76599b06e8ac28fa9988006927d7dfb9084d58008c74c2e4107b90ab897ae - W32/Kryptik.GLKH!tr


26997775beef04f801088cb5e130b505f9018685359070ac033839840ec7213c - W32/Kryptik.GLKH!tr


28bbe2e3133bfbbd624272349d35f6eb216346e5a0301cf83d01f12fbab13e93 - W32/Kryptik.GLKH!tr


6a9395cca0dafd3ec3af0bcb6487c1fb335cb6fa31af0790ac1b482783c531d7 - W32/Kryptik.GLKH!tr


8c2cc4f8f88052d2efa7937a0d522c32488c07aeb2589659c2d504cf662b92d8 - W32/Kryptik.GLKH!tr


941db28ae4b053747546753f48578e89f1a865117893fd8deecac86d909685b7 - W32/Kryptik.GLKH!tr


94d58958a7347b3dad471efa13b8e9ecef175254f4e585d23b98b2dbb0beb04c - W32/Kryptik.GLKH!tr


ad8849ef085c91865c13c66a4a6178b1c59dad0cf01c1d57ef21051444c45f79 - W32/Kryptik.GLKH!tr


b84d9c08fc35c3a160b4ee1f4061035a4bb9781e5f64e623ec988b8447b2c667 - W32/Kryptik.GLKH!tr


d8c5e17ae272728caf35bc7a9a45bbaa896da671af3b720683b7daa722696433 - W32/Kryptik.GLKH!tr


df73f03f85aa0e22801167f7399c2cc43e9403d167f51dc1dd4f5381110acd0b - W32/Kryptik.GLKH!tr

ee2b5f9229f897b960c50ae8a896990aa1ec54e4787f1312c771bfdf0214b850 - W32/Kryptik.GLKH!tr
































































Sign up for our weekly FortiGuard Threat Brief. Know your vulnerabilities – get the facts about your network security. A Fortinet Cyber Threat Assessment can help you better understand: Security and Threat Prevention, User Productivity, and Network Utilization and Performance.

Learn more about FortiGuard Labs and the FortiGuard Security Services portfolio.