mrmoor/cyber-threat-intelligence huggingface dataset:
There are also times when developers intentionally remove these associations and plant misleading information to avoid attribution.
That action by itself potentially introduces other leads that developers may forget to clean.
Operating system language version
During the analysis of the samples captured from the previous campaign related to SLUB in 2019, one of the samples, the SLUB loader exploiting CVE-2019-0803, contained a version resource section that included intentionally misleading planted data.
Figure 1 shows this:      Figure 1 Planted version information      This kind of misleading version data is quite common and does not have information relevant to attribution.
However, there is a secondary effect when the version resource is added to a binary.
For this, we are assuming this binary was compiled with a Visual Studio toolchain, which is indicated for various compiler identification tools.
When the version resource is compiled into the binary, a language ID is generated and created not in the resource payload but in the internal structure of the resource information that is not visible with Windows Explorer.
What is interesting is that this language ID is not determined by the Visual Studio current language.
Instead, it is determined by the operating system language at the time of the version resource inclusion.
Viewing this language ID requires the use of other tools.
Figure 2 shows the language ID for the SLUB dropper.
Figure 2. Language ID of the Version Resource
We found this type of OS language leak in prior samples attributed to APT37.
One of the previous malware families attributed to APT37 is known as Freenki.
Some Freenki samples had leaked the OS language ID through this same mechanism.
The image (Figure 3) taken from an analysis of Freenki shows that the same logic applies when the resource is compiled into the binary.
Figure 3. Freenki embedded resource
We assume there are multiple developers within APT37, and not all of them follow the same practices.
As such, not all samples may have the embedded resource that leaks the same OS language.
However, this commonality is just the first of many that lead us to believe the team attributed to the Freenki malware is the same team behind Operation Earth Kitsune.2 Leaked assert path and external blog references Sometimes, the malware authors know that releasing symbol information is dangerous from an attribution point of view since it can reveal information about the working environment.
That information often gets stripped from binaries.
However, that is not the only scenario where malware developers leak path information about their environment.
In some instances, malware projects require external libraries, and some libraries used the “assert()” mechanism to help the developers debug unexpected conditions.
In these cases, the compiler includes a path to the source code file along with those “assert()” calls.
These paths leak information about the third-party libraries’ installed paths.
In our case, the samples from the Operation Earth Kitsune implemented the Mattermost command and control (C2) communication and leaked a local path.
Figure 4 shows the leaked path.
Figure 4. Leaked assert() path     Public references to this path (the path to the c++ boost library) consist of Korean language blogs explaining how to set up a developer environment configuration using the same path.
We can also determine that this configuration was created manually because the default path installation does not support static compilation.
Here is a translation of the relevant section: “Well, in the end, I modified the project configuration file as below, but it doesn't seem like best practice.
There seems to be a neat way to do it, but I seek advice from experienced people.”
It is also important to note that the same paths leaked through all the SLUB samples.
This includes samples from the older SLUB campaign in 2019 and the new version that supports Mattermost.
Public blog in the Korean Language     These two indicators reveal that the malware author used an “assert()” path and referenced an external blog in the same manner as previously analyzed malware.
TTPs Correlation
In our previous detailed analysis of Operation Earth Kitsune, one of the delivery architecture for the espionage backdoors is designed as shown in Figure 6.      Figure 6.
Delivery architecture
While this mechanism may sound quite common in other campaigns, what is interesting is the details they have in common with previous campaigns attributed to APT37.
In 2017, Palo Alto’s Unit 42 detailed their findings around the Freenki malware.
Even though this analysis was three years before Operation Earth Kitsune, the attackers appear to have reused the same TTPs for delivering the malware.
Figure 7 shows delivery PowerShell script sections for both campaigns.
Figure 7. PowerShell scripts downloading JPG files     The following TTPs are common in both campaigns related to the scripts in Figure 7:
Both have compromised websites where the malware samples are hosted and delivered to victim machines.
Both use PowerShell scripts to download and run the samples.
Both PowerShell scripts download multiple malware to the victim machine.
It appears the attacker is willing to implement multiple mechanisms for infecting the victim machine once it is compromised.
Both use different samples for the multiple malware downloaded.
Both use JPG as a delivering extension.
In both cases, at least one sample received command line arguments.
Another surprising similarity in the TTPs related to both campaigns is the path pointing to “udel_ok.ipp,”  as shown in Figure 7.
This is a JavaScript file that executes with wscript.exe.
Figure 8 shows the partial source code for this JavaScript.
Figure 8. Javascript executing the malware.
What got our attention is that the samples were renamed to be similar to the naming convention of Windows update files (i.e., “Windows-KB275122-x86.exe”).
While analyzing the samples that have been previously attributed to APT37, we noticed that the persistence mechanism in Operation Earth Kitsune uses the same naming convention to auto-start itself through the Windows run registry key.
We also found that older samples from the previous SLUB campaigns in 2019 used a similar naming convention.
Figure 9 shows that SLUB used “Windows-RT-KB-2937636.dll,” while Freenki used “Windows-KB275122-x86.exe.”      Figure 9 Naming convention for persistence.
We can see how the Freenki malware, previous SLUB campaigns, and Operation Earth Kitsune share many common TTPs in their delivery and persistence mechanisms.
However, these are not the only commonalities.
Again, on its own, this might not be coincidental.
However, our analysis shows further similarities that imply correlation.
GNUBoard compromised web sites
In the blog describing Operation Earth Kitsune, we noted sites using the GNUBoard Content Management System (CMS) had been compromised and were used to host malware.
The malware campaigns previously attributed to APT37 also extensively used the exploitation of web sites hosted with GNUBoard CMS.
While analyzing multiple samples, we found indicators of this strategy across the various campaigns.
Figure 10 shows an example attributed to APT37 and Operation Earth Kitsune as a comparison.
The SLUB campaign also exploited and used GNUBoard websites as part of the infrastructure.
Websites created using GNUBoard CMS     Exfiltration commands
As mentioned in the previous report on Operation Earth Kitsune, one of the espionage backdoors, named agfSpy, received a “JSON” configuration with a list of native Windows commands to execute.
The output of those commands is exfiltrated back to the agfSpy command and control (C2) server.
While analyzing one malware previously attributed to APT37, it executed practically the same command sequences including the paths and extensions.
Even when the threat actor was not using the “JSON” format, the commands embedded in the various samples show a surprising amount of similarities.
Figure 11 shows a comparison of the exfiltration commands between malware previously attributed to APT37 and Operation Earth Kitsune.
Note the following similarities:  The usage of paths C:\Users and D:\ are similar The searching patterns are very similar The extension list is very similar
Note that we are comparting a sample from 2016 with agfSpy, which is from 2020.
It makes sense that new campaigns coming from the same authors/groups will add new extensions like “.xlsx” to support updated versions of Office documents.
It is also clear that the actual interest is on the “.hwp” extension for Korean Office document listing support during exfiltration.
Figure 11. Exfiltration command similarities.     Code sharing
When doing attribution, finding code sharing between different samples is one of the most desired discoveries.
However, in our case, this was difficult as we are comparing samples from 2016-2017 to those developed in 2020.
At the same time, practically all code for the SLUB malware was created from scratch.
Also, dneSpy and agfSpy are based on custom and newly developed code.
That makes it difficult to match code similarities, and that is why many of the indicators of code sharing are sparse across different samples.
However, one feature that is present in the previous malware attributed to APT37 and Operation Earth Kitsune is the screenshot capture.
We tried to find how this feature evolved across previous samples and the older SLUB samples.
During the analysis, we found a clear indication of code sharing for the screenshot functionality.
Figure 12 shows a comparison between the two samples.
While this code may have some related “internet code sharing post” origin, both samples share it.
They also have some changes that make sense, such as removing the error “failed to take…,” since this is not required for the malware functionality.
It is likely a late refactor to the code.
Screenshot functionality comparison between SLUB and APT37     Working Hours
Analyzing the compile time of binaries between different samples can also provide a level of correlation between samples.
While malware authors can fake this, useful information can still be gleaned with enough samples.
In our case, we collected many samples across 2020, and we found that the compile dates and times follow a logical timeline according to the malicious activity.
Based on our analysis, we believe the malware author did not fake the compile times of the binaries.
Other public references also used the compiled binary time of samples attributed to APT37.
When compared to the compile times seen in Operation Earth Kitsune, there are several similarities.
The compile times that are listed on binaries provide an estimate of the threat actor's working hours and help approximate possible time zones where the malware was developed.
It is fair to assume that the developers work on daily working times.
When you have many samples to analyze, you can refine that expectation over time.
Figure 14 (below) shows a raw comparison across many samples using two time zones.
We can see how the UTC+9 time zone matches those previously attributed to APT37 and those from Operation Earth Kitsune.
These both equate to the daily working times for that time zone.
Compile Time APT73 and Kitsune
During the capture of samples for Operation Earth Kitsune, we managed to dump information about the Mattermost server using its API and the token used by the malware itself.
Mattermost was being used as a C2 channel for the malware.
Part of the dumped information contained the action of the user with administration roles on the system.
That user was doing manual activities the majority of the time.
At the same time, we were able to locate the Mattermost server hosted in Greece, and that gave us the current time zone of the Mattermost server.
Having that reference, we plotted the actions of all users whose information we could obtain.
It is important to remember that, except for the administrator user, all other accounts were used as part of the malware deployment (SLUB malware).
Figure 15 shows a plot with “Y” representing the number of actions.
For example, an action for the SYSTEM_ADMIN could be to create a user, add a user to a channel, etc.
The “X” axis represents the hour of the day (in 24 hours).
No months are plotted, so this figure is like compressing all the activity across the full 2020-year in one day just to show the active hours in a day.
All the plots are located in UTC+9.
Mattermost server activity.
Figure 15 shows that User_3 and User_4 have like random counts.
This is because those accounts are actually the ones the malware used during the infection logging activities to the Mattermost server.
However, the SYSTEM_ADMIN account has a different pattern because the actions are mostly due to manual administration activities.
Unsurprisingly, the SYSTEM_ADMIN hours perfectly line up with the daily working hours at UTC+9.
While no attribution is perfect, there are striking similarities between the malware attributed to APT37 and Operation Earth Kitsune.
Little can be gleaned from each individual piece, but when viewed as a whole, the group behind Operation Earth Kitsune is likely the same one behind the Freenki malware and other malware campaigns attributed to APT37.
This is somewhat surprising, considering Operation Earth Kitsune’s espionage tools were entirely fresh-developed.
We can summarize the correlated indicators in a general form as:  Use of Korean language in the system environment of the developers Reuse of multiple TTPs during operation deployments:     GNUBoard compromised web sites     Multiple malware samples deployed at the same time     A similar organization in the deployment architecture Reliance on public services and watering hole attacks to compromised victims Some code reuse, even when the samples are completely different otherwise Working hours for both matches
Exfiltration techniques and information interest are very similar if not fully matched  While it is always possible for another group to imitate the TTPs of a different group to confuse attribution, there does not seem to be any indication of that here.
Instead, what we see in SLUB and Operation Earth Kitsune is the evolution of an advanced threat actor over time: one that builds on what worked in the past to become more efficient in the present.
Cybercriminals and malicious hackers have been shifting their tactics, techniques, and procedures (TTPs) to improve their ability to infiltrate an organization and stay under the radar of security professionals and solutions.
Moving to more targeted attack methods appears to be a mainstay among threat actors, which requires organizations to improve their visibility into the entire attack lifecycle.
Gone are the days in which these attacks only target the endpoint, and as such, an expanded connected threat defense is paramount.
Many organizations have been adopting EDR (Endpoint Detection & Response) as a way to obtain more data about attacks on the endpoint.
But as we’ve seen with even ransomware actors, the endpoint is being targeted less.
Rather, attacks are laterally moving within an organization to find critical systems that will allow them to increase their chance of the organization paying the ransom.
(See my recent webinar on trends in ransomware.)
This means the actors behind many financially motivated and targeted attacks will move across the network, and their tracks will be left in other areas of their network, not just on the endpoint.
Expanding EDR to include other areas is the definition of XDR.
The X could be network data, email or web data, data from cloud instances, and others.
This would allow an organization to get visibility into the entire attack lifecycle, including infiltration, lateral movement, and exfiltration.
This will improve the organization’s ability to prevent critical data exfiltration or the compromise of critical systems within their network.
The ability to do this requires a number of key components:   A security vendor who has solutions across the entire network, including cloud, gateway (email & web), network, server, endpoint (includes mobile), and IoT/IIoT Support for threat intelligence and data analytics.
This should be as automated as possible and should include 3rd party threat intelligence (i.e. CERT, ISAC, ISAO feeds) History of expertise in correlating multiple threat vectors and the use of AI and Machine Learning
This will require a major shift from traditional security practices, as many organizations have supported a best-of-breed approach, utilizing multiple vendors (some say 50-100 security applications on average within a large enterprise).
Instead, the future is moving to a more consolidated approach with fewer vendors.
Having multiple vendors for different areas of security results in silos and segmentation due to a lack of integration across the security industry, but XDR could bring a shift in this practice as they include more support for 3rd party intelligence feeds.
Trend Micro has been innovating for 30 years and our breadth of security products allows us to successfully build an XDR solution.
Also, our almost 15 years of investing in and building AI/Machine Learning technologies into our backend and frontend products will allow us to have the data analytics piece covered.
Lastly, we have an extensive array of global threat intelligence that will allow us to ensure we can proactively detect and protect our customers.
Stay tuned for more information about this topic in upcoming blogs.
Tags  Cloud | Malware | APT & Targeted Attacks | Cyber Crime | Expert Perspective
On March 8, President Biden signed an Executive Order to ban the sale of Russian oil, liquefied natural gas and coal to the United States.
With bipartisan support, the decision was made to deprive the Putin regime of the economic resources needed to wage war in Ukraine.
However, marking as it does an escalation in punitive actions directed at the Russian state, it may also put US companies more directly in the firing line of cyber-attacks from the east.
Leaders of the U.S. intelligence community expressed this same concern in their annual appearance on capitol hill on Tuesday.
The Director of National Intelligence Avril Haines said “Nevertheless, our analysts assess that Putin is unlikely to be deterred by such setbacks and instead may escalate, essentially doubling down.”
The good news is that best practice cybersecurity advice does not need to change.
If the security and intelligence community continues to come together to share what information we have on offensive Russian cyber activity, and customers have the right detection and response tools in place, organizations can maintain a strong defensive posture.
Waiting for the tipping point
To date, the scale of Russian state-sponsored and proxy cyber-attacks has not been as expected.
Yes, we’ve seen continuous DDoS attacks, a campaign of web defacements and various iterations of wiper malware.
But these efforts have been mainly targeted at Ukrainian organizations.
Reports suggest tens of thousands of cybersecurity professionals there have enlisted as volunteers to help the country’s efforts.
Hacking collective Anonymous has also claimed responsibility for multiple hacktivist attacks in Russia.
However, following the Presidential EO this week, we could well see Russian APT groups or their proxies expand their targeting of U.S. critical infrastructure.
Oil and gas, banking and defense sectors are most likely to top of the list of targets.
What we can expect If this kind of escalation were to take place, it may begin through deployment of known destructive malware like IsaacWiper, HermeticWiper and WhisperKill onto already compromised targets or systems known to be vulnerable.
Follow-on phases would see the use of DDoS or other volumetric, availability-based attacks against systems that couldn’t be compromised in the first round of attacks.
Zero-day vulnerabilities held in reserve could be exploited during this phase.
Alongside the threat from Russian state hackers, Putin may call upon the “patriotic” reserves of the numerous cybercrime groups operating from within the country.
Already the Conti and Lockbit ransomware collectives have stated their support.
However, Conti was forced to equivocate its language after a Ukrainian researcher doxxed the group with a devastating leak of source code and other internal information.
Although they may not have a choice if called upon to support the Kremlin, this incident will certainly give many Russian ransomware actors a reason to think twice about joining the war effort.
Fighting back If the worst-case scenario does unfold and US organizations are attacked en masse, normal rules of best practice cybersecurity apply.
First comes continuous risk-based patching, multi-factor authentication, network monitoring, least privilege access, data encryption, phishing awareness training, and other cyber-hygiene steps.
But on top of that, organizations must have the detection and response tooling, ideally XDR, to correlate, prioritize and act on high fidelity alerts with speed and precision.
The security community, including government agencies, should quicken their pace in sharing actionable intelligence, in order to improve public and private organizations’ threat hunting and detection efforts.
Security operations (SecOPs) leaders may also want to:  Expand training and awareness for their users and partners; Collect telemetry from sources not traditionally aligned with cyber such as supply chain vendor management.
Increase attack surface enumeration across IoT, Industrial IoT, mobile and cloud; Expand or deploy a zero trust architecture framework and;  Fortify your backups
Tags  Expert Perspective | Web | Exploits & Vulnerabilities | Cyber Threats | APT & Targeted Attacks | Articles, News, Reports | Network
With additional analysis from Cyber Safety Solutions Team Developers constantly need to modify and rework their source codes when releasing new versions of applications or coding projects they create and maintain.
This is what makes GitHub—an online repository hosting service that provides version control management—popular.
In many ways, it’s like a social networking site for programmers and developers, one that provides a valuable platform for code management, sharing, collaboration, and integration.
GitHub is no stranger to misuse, however.
Open-source ransomware projects EDA2 and Hidden Tear—supposedly created for educational purposes—were hosted on GitHub, and have since spawned various offshoots that have been found targeting enterprises.
Tools that exploited vulnerabilities in Internet of Things (IoT) devices were also made available on GitHub.
Even the Limitless Keylogger, which was used in targeted attacks, was linked to a GitHub project.
Recently, the Winnti group, a threat actor with a past of traditional cybercrime -particularly with financial fraud, has been seen abusing GitHub by turning it into a conduit for the command and control (C&C) communications of their seemingly new backdoor (detected by Trend Micro as BKDR64_WINNTI.ONM).
Our research also showed that the group still uses some of the infamous PlugX malware variants—a staple in Winnti’s arsenal—to handle targeted attack operations via the GitHub account we identified.
The malware we analyzed is separated in two files: a loader, and the payload.
The loader, named loadperf.dll, is a modified version of its legitimate, similarly named counterpart—a Microsoft file which helps manipulate the performance registry.
An extra component has been added to its sections.
It copies itself on %WINDIR%\system32\wbem\ and replaces the original DLL.
It leverages the WMI performance adapter service (wmiAPSrv), a legitimate file in Windows that collects information related to system performance, to import the loader via services.exe.
The system also imports all related DLL files and includes the payload “loadoerf.ini”.
The infection chain includes an additional (albeit empty) function imported from loadoerf.ini, gzwrite64, which works as a fake Application Program Interface (API) that serves as the payload’s entry point.
Although gzwrite64 is imported by loadperf.dll, the payload’s main function is actually located in the DLLMain of “loadoerf.ini”.