Users are encouraged to take these warnings seriously and consider enrolling in the Advanced Protection Program or enabling two-factor authentication if they haven't already.


We also block malicious domains using Google Safe Browsing – a service that Google's security team built to identify unsafe websites across the web and notify users and website owners of potential harm.


When a user of a Safe Browsing-enabled browser or app attempts to access unsafe content on the web, they’ll see a warning page explaining that the content they’re trying to access may be harmful.


When a site identified by Safe Browsing as harmful appears in Google Search results, we show a warning next to it in the results.


Threat Analysis Group will continue to identify bad actors and share relevant information with others in the industry, with the goal of bringing awareness to these issues, protecting you and fighting bad actors to prevent future attacks.


Indicators from APT28 phishing campaign: service-reset-password-moderate-digital.rf[.]gd reset-service-identity-mail.42web[.]io digital-email-software.great-site[.]net  Indicators from APT35 campaigns:  Abused Google Properties: https://sites.google[.]com/view/ty85yt8tg8-download-rtih4ithr/ https://sites.google[.]com/view/user-id-568245/ https://sites.google[.]com/view/hhbejfdwdhwuhscbsb-xscvhdvbc/  Abused Dropbox Properties: https://www.dropbox[.]com/s/68y4vpfu8pc3imf/Iraq&Jewish.pdf


Phishing Domains: nco2[.]live summit-files[.]com filetransfer[.]club continuetogo[.]me accessverification[.]online customers-verification-identifier[.]site service-activity-session[.]online identifier-service-review[.]site recovery-activity-identification[.]site review-session-confirmation[.]site recovery-service-activity[.]site verify-service-activity[.]site service-manager-notifications[.]info


Android App: https://www.virustotal.com/gui/file/5d3ff202f20af915863eee45916412a271bae1ea3a0e20988309c16723ce4da5/detection  Android App C2: communication-shield[.]site cdsa[.]xyz


Google’s Threat Analysis Group tracks actors involved in disinformation campaigns, government backed hacking, and financially motivated abuse.


Understanding the techniques used by attackers helps us counter these threats effectively.


This blog post is intended to highlight a new evasion technique we identified, which is currently being used by a financially motivated threat actor to avoid detection.


Attackers often rely on varying behaviors between different systems to gain access.


For instance, attacker’s may bypass filtering by convincing a mail gateway that a document is benign so the computer treats it as an executable program.


In the case of the attack outlined below, we see that attackers created malformed code signatures that are treated as valid by Windows but are not able to be decoded or checked by OpenSSL code — which is used in a number of security scanning products.


We believe this is a technique the attacker is using to evade detection rules.


Code signatures on Windows executables provide guarantees about the integrity of a signed executable, as well as information about the identity of the signer.


Attackers who are able to obscure their identity in signatures without affecting the integrity of the signature can avoid detection longer and extend the lifetime of their code-signing certificates to infect more systems.


OpenSUpdater, a known family of unwanted software which violates our policies and is harmful to the user experience, is used to download and install other suspicious programs.


The actor behind OpenSUpdater tries to infect as many users as possible and while they do not have specific targeting, most targets appear to be within the United States and prone to downloading game cracks and grey-area software.


Groups of OpenSUpdater samples are often signed with the same code-signing certificate, obtained from a legitimate certificate authority.


Since mid-August, OpenSUpdater samples have carried an invalid signature, and further investigation showed this was a deliberate attempt to evade detection.


In these new samples, the signature was edited such that an End of Content (EOC) marker replaced a NULL tag for the 'parameters' element of the SignatureAlgorithm signing the leaf X.509 certificate.


EOC markers terminate indefinite-length encodings, but in this case an EOC is used within a definite-length encoding (l= 13).


Bytes: 30 0D 06 09 2A 86 48 86  F7 0D 01 01 0B 00 00


Decodes to the following elements: SEQUENCE (2 elem) OBJECT IDENTIFIER 1.2.840.113549.1.1.11 sha256WithRSAEncryption (PKCS #1) EOC  Security products using OpenSSL to extract signature information will reject this encoding as invalid.


However, to a parser that permits these encodings, the digital signature of the binary will otherwise appear legitimate and valid.


This is the first time TAG has observed actors using this technique to evade detection while preserving a valid digital signature on PE files.


As shown in the following screenshot, the signature is considered to be valid by the Windows operating system.


This issue has been reported to Microsoft.


Since first discovering this activity, OpenSUpdater's authors have tried other variations on invalid encodings to further evade detection.


The following are samples using this evasion: https://www.virustotal.com/gui/file/5094028a0afb4d4a3d8fa82b613c0e59d31450d6c75ed96ded02be1e9db8104f/detection


New variant: https://www.virustotal.com/gui/file/5c0ff7b23457078c9d0cbe186f1d05bfd573eb555baa1bf4a45e1b79c8c575db/detection


Our team is working in collaboration with Google Safe Browsing to protect users from downloading and executing this family of unwanted software.


Users are encouraged to only download and install software from reputable and trustworthy sources.


Zero-day vulnerabilities are unknown software flaws.


Until they’re identified and fixed, they can be exploited by attackers.


Google’s Threat Analysis Group (TAG) actively works to detect hacking attempts and influence operations to protect users from digital attacks, this includes hunting for these types of vulnerabilities because they can be particularly dangerous when exploited and have a high rate of success.


In this blog, we’re sharing details about four in-the-wild 0-day campaigns targeting four separate vulnerabilities we’ve discovered so far this year: CVE-2021-21166 and CVE-2021-30551 in Chrome, CVE-2021-33742 in Internet Explorer, and CVE-2021-1879 in WebKit (Safari).


The four exploits were used as a part of three different campaigns.


As is our policy, after discovering these 0-days, we quickly reported to the vendor and patches were released to users to protect them from these attacks.


We assess three of these exploits were developed by the same commercial surveillance company that sold these capabilities to two different government-backed actors.


Google has also published root cause analyses (RCAs) on each of the 0-days.


In addition to the technical details, we’ll also provide our take on the large uptick of in-the-wild 0-day attacks the industry is seeing this year.


Halfway into 2021, there have been 33 0-day exploits used in attacks that have been publicly disclosed this year — 11 more than the total number from 2020.


While there is an increase in the number of 0-day exploits being used, we believe greater detection and disclosure efforts are also contributing to the upward trend.


Over the past several months, we have discovered two Chrome renderer remote code execution 0-day exploits, CVE-2021-21166 and CVE-2021-30551, which we believe to be used by the same actor.


CVE-2021-21166 was discovered in February 2021 while running Chrome 88.0.4323.182 and CVE-2021-30551 was discovered in June 2021 while running Chrome 91.0.4472.77.


Both of these 0-days were delivered as one-time links sent by email to the targets, all of whom we believe were in Armenia.


The links led to attacker-controlled domains that mimicked legitimate websites related to the targeted users.


When a target clicked the link, they were redirected to a webpage that would fingerprint their device, collect system information about the client and generate ECDH keys to encrypt the exploits, and then send this data back to the exploit server.


The information collected from the fingerprinting phase included screen resolution, timezone, languages, browser plugins, and available MIME types.


This information was collected by the attackers to decide whether or not an exploit should be delivered to the target.


Using appropriate configurations, we were able to recover two 0-day exploits (CVE-2021-21166 & CVE-2021-30551), which were targeting the latest versions of Chrome on Windows at the time of delivery.


After the renderer is compromised, an intermediary stage is executed to gather more information about the infected device including OS build version, CPU, firmware and BIOS information.


This is likely collected in an attempt to detect virtual machines and deliver a tailored sandbox escape to the target.


In our environment, we did not receive any payloads past this stage.


While analyzing CVE-2021-21166 we realized the vulnerability was also in code shared with WebKit and therefore Safari was also vulnerable.


Apple fixed the issue as CVE-2021-1844.


We do not have any evidence that this vulnerability was used to target Safari users.


Related IOCs lragir[.]org armradio[.]org asbares[.]com armtimes[.]net armlur[.]org armenpress[.]org hraparak[.]org armtimes[.]org hetq[.]org


Despite Microsoft announcing the retirement of Internet Explorer 11, planned for June 2022, attackers continue to develop creative ways to load malicious content inside Internet Explorer engines to exploit vulnerabilities.


For example, earlier this year, North Korean attackers distributed MHT files embedding an exploit for CVE-2021-26411.


These files are automatically opened in Internet Explorer when they are double clicked by the user.


In April 2021, TAG discovered a campaign targeting Armenian users with malicious Office documents that loaded web content within Internet Explorer.


This happened by either embedding a remote ActiveX object using a Shell.Explorer.1 OLE object or by spawning an Internet Explorer process via VBA macros to navigate to a web page.


At the time, we were unable to recover the next stage payload, but successfully recovered the exploit after an early June campaign from the same actors.


After a fingerprinting phase, similar to the one used with the Chrome exploit above, users were served an Internet Explorer 0-day.


This vulnerability was assigned CVE-2021-33742 and fixed by Microsoft in June 2021.


The exploit loaded an intermediary stage similar to the one used in the Chrome exploits.


We did not recover additional payloads in our environment.


During our investigation we discovered several documents uploaded to VirusTotal.


Based on our analysis, we assess that the Chrome and Internet Explorer exploits described here were developed and sold by the same vendor providing surveillance capabilities to customers around the world.


On July 15, 2021 Citizen Lab published a report tying the activity to spyware vendor Candiru.


Related IOCs


Examples of related Office documents uploaded to VirusTotal: https://www.virustotal.com/gui/file/656d19186795280a068fcb97e7ef821b55ad3d620771d42ed98d22ee3c635e67/detection https://www.virustotal.com/gui/file/851bf4ab807fc9b29c9f6468c8c89a82b8f94e40474c6669f105bce91f278fdb/detection


Unique URLs serving CVE-2021-33742 Internet Explorer exploit: http://lioiamcount[.]com/IsnoMLgankYg6/EjlYIy7cdFZFeyFqE4IURS1 http://db-control-uplink[.]com/eFe1J00hISDe9Zw/gzHvIOlHpIXB http://kidone[.]xyz/VvE0yYArmvhyTl/GzV


Word documents with the following classid: {EAB22AC3-30C1-11CF-A7EB-0000C05BAE0B} Related infrastructure: workaj[.]com wordzmncount[.]com Not all attacks require chaining multiple 0-day exploits to be successful.


A recent example is CVE-2021-1879 that was discovered by TAG on March 19, 2021, and used by a likely Russian government-backed actor.


(NOTE: This exploit is not connected to the other three we’ve discussed above.)


In this campaign, attackers used LinkedIn Messaging to target government officials from western European countries by sending them malicious links.


If the target visited the link from an iOS device, they would be redirected to an attacker-controlled domain that served the next stage payloads.


The campaign targeting iOS devices coincided with campaigns from the same actor targeting users on Windows devices to deliver Cobalt Strike, one of which was previously described by Volexity.


After several validation checks to ensure the device being exploited was a real device, the final payload would be served to exploit CVE-2021-1879.


This exploit would turn off Same-Origin-Policy protections in order to collect authentication cookies from several popular websites, including Google, Microsoft, LinkedIn, Facebook and Yahoo and send them via WebSocket to an attacker-controlled IP.


The victim would need to have a session open on these websites from Safari for cookies to be successfully exfiltrated.


There was no sandbox escape or implant delivered via this exploit.


The exploit targeted iOS versions 12.4 through 13.7.


This type of attack, described by Amy Burnett in Forget the Sandbox Escape: Abusing Browsers from Code Execution, are mitigated in browsers with Site Isolation enabled such as Chrome or Firefox.


Related IOCs supportcdn.web[.]app vegmobile[.]com 111.90.146[.]198


There is not a one-to-one relationship between the number of 0-days being used in-the-wild and the number of 0-days being detected and disclosed as in-the-wild.


The attackers behind 0-day exploits generally want their 0-days to stay hidden and unknown because that’s how they’re most useful.


Based on this, there are multiple factors that could be contributing to the uptick in the number of 0-days that are disclosed as in-the-wild: Increase in detection & disclosure


This year, Apple began annotating vulnerabilities in their security bulletins to include notes if there is reason to believe that a vulnerability may be exploited in-the-wild and Google added these annotations to their Android bulletins.


When vendors don’t include these annotations, the only way the public can learn of the in-the-wild exploitation is if the researcher or group who knows of the exploitation publishes the information themselves.


In addition to beginning to disclose when 0-days are believed to be exploited in-the-wild, it wouldn’t be surprising if there are more 0-day detection efforts, and successes, occurring as a result.


It’s also possible that more people are focusing on discovering 0-days in-the-wild and/or reporting the 0-days that they found in the wild.


Increased Utilization


There is also the possibility that attackers are using more 0-day exploits.


There are a few reasons why this is likely:    Over the last decade, we believe there has been an increase in attackers using 0-day exploits.


Attackers needing more 0-day exploits to maintain their capabilities is a good thing — and it


reflects increased cost to the attackers from security measures that close known vulnerabilities.


However, the increasing demand for these capabilities and the ecosystem that supplies them is more of a challenge.


0-day capabilities used to be only the tools of select nation states who had the technical expertise to find 0-day vulnerabilities, develop them into exploits, and then strategically operationalize their use.


In the mid-to-late 2010s, more private companies have joined the marketplace selling these 0-day capabilities.


No longer do groups need to have the technical expertise, now they just need resources.


Three of the four 0-days that TAG has discovered in 2021 fall into this category: developed by commercial providers and sold to and used by government-backed actors.


Meanwhile, improvements in detection and a growing culture of disclosure likely contribute to the significant uptick in 0-days detected in 2021 compared to 2020, but reflect more positive trends.


Those of us working on protecting users from 0-day attacks have long suspected that overall, the industry detects only a small percentage of the 0-days actually being used.


Increasing our detection of 0-day exploits is a good thing — it allows us to get those vulnerabilities fixed and protect users, and gives us a fuller picture of the exploitation that is actually happening so we can make more informed decisions on how to prevent and fight it.


We’d be remiss if we did not acknowledge the quick response and patching of these vulnerabilities by the Apple, Google, and Microsoft teams.


In January, the Threat Analysis Group documented a hacking campaign, which we were able to attribute to a North Korean government-backed entity, targeting security researchers.


On March 17th, the same actors behind those attacks set up a new website with associated social media profiles for a fake company called “SecuriElite.”


The new website claims the company is an offensive security company located in Turkey that offers pentests, software security assessments and exploits.


Like previous websites we’ve seen set up by this actor, this website has a link to their PGP public key at the bottom of the page.


In January, targeted researchers reported that the PGP key hosted on the attacker’s blog acted as the lure to visit the site where a browser exploit was waiting to be triggered.


The attacker’s latest batch of social media profiles continue the trend of posing as fellow security researchers interested in exploitation and offensive security.


On LinkedIn, we identified two accounts impersonating recruiters for antivirus and security companies.


We have reported all identified social media profiles to the platforms to allow them to take appropriate action.


At this time, we have not observed the new attacker website serve malicious content, but we have added it to Google Safebrowsing as a precaution.


Following our January blog post, security researchers successfully identified these actors using an Internet Explorer 0-day.


Based on their activity, we continue to believe that these actors are dangerous, and likely have more 0-days.


We encourage anyone who discovers a Chrome vulnerability to report that activity through the Chrome Vulnerabilities Rewards Program submission process.


Fake Security Company Website:     LinkedIn Profiles:    Email:    Attacker Owned Domains:        Over the past several months, the Threat Analysis Group has identified an ongoing campaign targeting security researchers working on vulnerability research and development at different companies and organizations.


The actors behind this campaign, which we attribute to a government-backed entity based in North Korea, have employed a number of means to target researchers which we will outline below.


We hope this post will remind those in the security research community that they are targets to government-backed attackers and should remain vigilant when engaging with individuals they have not previously interacted with.


In order to build credibility and connect with security researchers, the actors established a research blog and multiple Twitter profiles to interact with potential targets.


They've used these Twitter profiles for posting links to their blog, posting videos of their claimed exploits and for amplifying and retweeting posts from other accounts that they control.


Their blog contains write-ups and analysis of vulnerabilities that have been publicly disclosed, including “guest” posts from unwitting legitimate security researchers, likely in an attempt to build additional credibility with other security researchers.


While we are unable to verify the authenticity or the working status of all of the exploits that they have posted videos of, in at least one case, the actors have faked the success of their claimed working exploit.


On Jan 14, 2021, the actors shared via Twitter a YouTube video they uploaded that proclaimed to exploit CVE-2021-1647, a recently patched Windows Defender vulnerability.


In the video, they purported to show a successful working exploit that spawns a cmd.exe shell, but a careful review of the video shows the exploit is fake.


Multiple comments on YouTube identified that the video was faked and that there was not a working exploit demonstrated.


After these comments were made, the actors used a second Twitter account (that they control) to retweet the original post and claim that it was “not a fake video.”


The actors have been observed targeting specific security researchers by a novel social engineering method.


After establishing initial communications, the actors would ask the targeted researcher if they wanted to collaborate on vulnerability research together, and then provide the researcher with a Visual Studio Project.


Within the Visual Studio Project would be source code for exploiting the vulnerability, as well as an additional DLL that would be executed through Visual Studio Build Events.


The DLL is custom malware that would immediately begin communicating with actor-controlled C2 domains.


An example of the VS Build Event can be seen in the image below.


In addition to targeting users via social engineering, we have also observed several cases where researchers have been compromised after visiting the actors’ blog.


In each of these cases, the researchers have followed a link on Twitter to a write-up hosted on blog.br0vvnn[.]io, and shortly thereafter, a malicious service was installed on the researcher’s system and an in-memory backdoor would begin beaconing to an actor-owned command and control server.


At the time of these visits, the victim systems were running fully patched and up-to-date Windows 10 and Chrome browser versions.


At this time we’re unable to confirm the mechanism of compromise, but we welcome any information others might have.


Chrome vulnerabilities, including those being exploited in the wild (ITW), are eligible for reward payout under Chrome's Vulnerability Reward Program.


We encourage anyone who discovers a Chrome vulnerability to report that activity via the Chrome VRP submission process.


These actors have used multiple platforms to communicate with potential targets, including Twitter, LinkedIn, Telegram, Discord, Keybase and email.


We are providing a list of known accounts and aliases below.


If you have communicated with any of these accounts or visited the actors’ blog, we suggest you review your systems for the IOCs provided below.


To date, we have only seen these actors targeting Windows systems as a part of this campaign.


If you are concerned that you are being targeted, we recommend that you compartmentalize your research activities using separate physical or virtual machines for general web browsing, interacting with others in the research community, accepting files from third parties and your own security research.


Host IOCs Registry Keys HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\KernelConfig HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\DriverConfig HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Run\SSL Update File Paths C:\Windows\System32\Nwsapagent.sys C:\Windows\System32\helpsvc.sys C:\ProgramData\USOShared\uso.bin C:\ProgramData\VMware\vmnat-update.bin C:\ProgramData\VirtualBox\update.bin


This bulletin includes coordinated influence operation campaigns terminated on our platforms in Q4 2020.


It was last updated on January 26, 2021.


We terminated 12 YouTube channels as part of our ongoing investigation into coordinated influence operations linked to Russia.


This campaign uploaded content in Russian supporting the Russian military and criticizing U.S. military involvement in Japan.


We received leads from Facebook that supported us in this investigation.


We terminated 2 YouTube channels as part of our investigation into coordinated influence operations linked to Myanmar.


This domestic campaign posted content focused on elections and supporting the Union Solidarity and Development Party, (USDP).


This campaign was consistent with similar findings reported by Facebook.


We terminated 35 YouTube channels as part of our investigation into coordinated influence operations linked to Azerbaijan.


This domestic campaign was linked to the New Azerbaijan Party and posted content supporting the Azerbaijani government and promoting Azerbaijani nationalism.


We terminated 26 YouTube channels and 1 blog as part of our ongoing investigation into coordinated influence operations linked to Russia.


This campaign uploaded content primarily in Russian and included news clips and military videos supporting the Russian government.


We received leads from the FBI that supported us in this investigation.


We terminated 2 YouTube channels as part of our ongoing investigation into a coordinated influence operation linked to Iran.


This campaign uploaded content in Farsi and Arabic that was critical of the Saudi government.


We terminated 10 YouTube channels as part of our ongoing investigation into coordinated influence operations linked to Russia.


This campaign uploaded content in Ukrainian about current events in Ukraine and critical of President Zelensky and former Ukrainian President Petro Poroshenko.


We terminated 22 YouTube channels as part of our ongoing investigation into coordinated influence operations linked to Indonesia.


This domestic campaign posted content supporting the Indonesian government.


We terminated 2 YouTube channels and 1 blog as part of our ongoing investigation into coordinated influence operations linked to Iran.


This campaign posted content in Arabic about the Syrian civil war and critical of U.S. foreign policy.


We terminated 3 YouTube channels as part of our ongoing investigation into coordinated influence operations linked to Iran.


This campaign posted content in English, Hebrew, and Arabic supporting anti-government protests in Israel.


We terminated 9 YouTube channels as part of our investigation into a coordinated influence operation linked to Egypt.


This campaign posted content in Arabic supportive of the Muslim Brotherhood and critical of Israel and Saudi Arabia.


This campaign was consistent with similar findings reported by Facebook.


We terminated 6 YouTube channels as part of our ongoing investigation into coordinated influence operations linked to Iran.


This campaign posted content in Farsi and Dari about current events and included some content that misrepresented itself as Turkish and Afghan news outlets.


We terminated 1 YouTube channel as part of our ongoing investigation into coordinated influence operations linked to Myanmar.


This domestic campaign was linked to the Arakan Army and posted content that misrepresented itself as local news.


We terminated 1 YouTube channel and 1 advertising account as part of our ongoing investigation into coordinated influence operations linked to Russia.


This campaign uploaded content in Russian critical of the Ukrainian government.


We terminated 1 blog as part of our investigation into coordinated influence operations linked to Argentina.


The campaign uploaded content in Spanish that was critical of an Ecuadorian member of parliament.


We terminated 5 YouTube channels and 2 blogs as part of our ongoing investigation into coordinated influence operations linked to Russia.


This campaign uploaded content in Arabic about current events in the Middle East and North Africa.


We terminated 3 YouTube channels as part of our investigation into coordinated influence operations linked to France.


This campaign uploaded content in French that was supportive of the French government and critical of the Russian government.


The campaign targeted the Central African Republic and Mali.


We terminated 34 YouTube channels as part of our ongoing investigation into coordinated influence operations linked to Myanmar.


This domestic campaign uploaded content about the Myanmar elections, regional conflicts, and current events related to the U.S., China, and Malaysia.


We terminated 3,317 YouTube channels as part of our ongoing investigation into coordinated influence operations linked to China.


These channels mostly uploaded spammy content in Chinese about music, entertainment, and cooking.


A very small subset uploaded content in Chinese and English about the U.S. response to COVID-19 and anti-Chinese sentiment in the U.S.


We received leads from Graphika and Fireye that supported us in this investigation.


These findings are consistent with our previous reports in the Q2 and Q3 TAG bulletins.


Major events like elections and COVID-19 present opportunities for threat actors, and Google’s Threat Analysis Group (TAG) is working to thwart these threats and protect our products and the people using them.


As we head into the U.S. election, we wanted to share an update on what we’re seeing and how threat actors are changing their tactics.


In June, we announced that we saw phishing attempts against the personal email accounts of staffers on the Biden and Trump campaigns by Chinese and Iranian APTs (Advanced Persistent Threats) respectively.


We haven’t seen any evidence of such attempts being successful.


The Iranian attacker group (APT35) and the Chinese attacker group (APT31) targeted campaign staffers’ personal emails with credential phishing emails and emails containing tracking links.


As part of our wider tracking of APT31 activity, we've also seen them deploy targeted malware campaigns.


One APT31 campaign was based on emailing links that would ultimately download malware hosted on GitHub.


The malware was a python-based implant using Dropbox for command and control.


It would allow the attacker to upload and download files as well as execute arbitrary commands.


Every malicious piece of this attack was hosted on legitimate services, making it harder for defenders to rely on network signals for detection.


In one example, attackers impersonated McAfee.


The targets would be prompted to install a legitimate version of McAfee anti-virus software from GitHub, while malware was simultaneously silently installed to the system.


When we detect that a user is the target of a government-backed attack, we send them a prominent warning.


In these cases, we also shared our findings with the campaigns and the Federal Bureau of Investigation.


This targeting is consistent with what others have subsequently reported.


Overall, we’ve seen increased attention on the threats posed by APTs in the context of the U.S. election.


U.S government agencies have warned about different threat actors, and we’ve worked closely with those agencies and others in the tech industry to share leads and intelligence about what we’re seeing across the ecosystem.


This has resulted in action on our platforms, as well as others.


Shortly after the U.S. Treasury sanctioned Ukrainian Parliament member Andrii Derkach for attempting to influence the U.S. electoral process, we removed 14 Google accounts that were linked to him.


We’ve been sharing actions against coordinated influence operations in our quarterly TAG bulletin (check out our Q1, Q2 and Q3 updates).


To date, TAG has not identified any significant coordinated influence campaigns targeting, or attempting to influence, U.S. voters on our platforms.


Since last summer, TAG has tracked a large spam network linked to China attempting to run an influence operation, primarily on YouTube.


This network has a presence across multiple platforms, and acts by primarily acquiring or hijacking existing accounts and posting spammy content in Mandarin such as videos of animals, music, food, plants, sports, and games.


A small fraction of these spam channels will then post videos about current events.


Such videos frequently feature clumsy translations and computer-generated voices.


Researchers at Graphika and FireEye have detailed how this network behaves—including its shift from posting content in Mandarin about issues related to Hong Kong and China’s response to COVID-19, to including a small subset of content in English and Mandarin about current events in the U.S. (such as protests around racial justice, the wildfires on the West Coast, and the U.S. response to COVID-19).


As the course of the COVID-19 pandemic evolves, we’ve seen threat actors evolve their tactics as well.


In previous posts, we discussed targeting of health organizations as well as attacker efforts to impersonate the World Health Organization.


This summer, we and others observed threat actors from China, Russia and Iran targeting pharmaceutical companies and researchers involved in vaccine development efforts.


In September, we started to see multiple North Korea groups shifting their targeting towards COVID-19 researchers and pharmaceutical companies, including those based in South Korea.


One campaign used URL shorteners and impersonated the target’s webmail portal in an attempt to harvest email credentials.


In a separate campaign, attackers posed as recruiting professionals to lure targets into downloading malware.


In the threat actor toolkit, different types of attacks are used for different purposes: Phishing campaigns can be used like a scalpel—targeting specific groups or individuals with personalized lures that are more likely to trick them into taking action (like clicking on a malware link), while DDoS attacks are more like a hatchet—disrupting or blocking a site or a service entirely.


While it’s less common to see DDoS attacks rather than phishing or hacking campaigns coming from government-backed threat groups, we’ve seen bigger players increase their capabilities in launching large-scale attacks in recent years.


For example in 2017, our Security Reliability Engineering team measured a record-breaking UDP amplification attack sourced out of several Chinese ISPs (ASNs 4134, 4837, 58453, and 9394), which remains the largest bandwidth attack of which we are aware.


Addressing state-sponsored DDoS attacks requires a coordinated response from the internet community, and we work with others to identify and dismantle infrastructure used to conduct attacks.


Going forward, we’ll also use this blog to report attribution and activity we see in this space from state-backed actors when we can do so with a high degree of confidence and in a way that doesn’t disclose information to malicious actors.


Advanced persistent threats (APT) are known — and are universally dreaded — for their stealth.


Actors behind such attacks actively innovate their techniques to evade detection and ensure that they maintain a foothold inside an environment as long as possible.


Through the Apex One with Endpoint Sensor (iES), we discovered one such incident wherein an attacker utilized sophisticated techniques in an attempt to exfiltrate sensitive information from a company.


The unique tactics, techniques, and procedures (TTPs) used in this attack highlight the importance of cross-layered detection and response solutions.


Technical analysis Detection


We noticed the execution of schtasks.exe with the command line parameter “schtasks /create /tn <name> c:\programdata\<software name>\<file name>.bat /sc /once /st <time> /ru <user account>”.


The scheduled task was not created for persistence.


The batch file that was to be executed had a suspicious name that stood out.


This prompted us to dig deeper.


Evasion


The image file of the process residing in the Windows directory that triggered the schtasks command was marked as normal.


However, a quick check on VirusTotal showed that the file's name and usual location differed from what was found in the victim machine.


PlugX and  malicious BLOBs


The normal file loads a seemingly normal dynamic-link library (DLL) named after a common Microsoft DLL.


However, we saw that the hash of the DLL does not match any of the known hashes of a normal DLL.


Reversing the file revealed that it was the PlugX loader, a remote access tool (RAT) that has been historically used in attacks targeting government-related industries and organizations.


We then observed that it decrypts, loads, and executes another DLL file named after another Microsoft DLL file, but is actually an encrypted Binary Large Object (BLOB).


Figure 1 below shows the relationship between these three files.


Figure 1.


The relationship between the normal file used, the PlugX, and the malicious BLOB      Despite being around for quite some time, PlugX is still effective at evading detection.


The variant used in this attack has three parts:  A normal file A DLL loader that the normal file expects to be present An encrypted BLOB file containing the malicious code  Of the three, the loader would be the easiest to detect.


However, because the file is so simple and straightforward, it is easy for attackers to create multiple versions of the said file to evade detection.


Detection support for the BLOB is probably low.


Because of its being “free form,” detection engines would have a hard time parsing through its contents to find the malicious code which potentially made detection for EPPs and EDR difficult.


Aside from this, changing the encryption mechanism or packer would result in a totally different BLOB.


It should be noted that we have also observed an increase use of BLOB files since 2020.


The malicious code would run in the address space of the normal file.


This could allow the malicious code to evade behavior-monitoring features as endpoint protection platforms (EPP) would see the process as normal.


This is detailed in the next section.


A closer look at PlugX svchost injection


This variant of PlugX (detected by Trend Micro as Backdoor.Win32.PLUGX.DYSGUT), including the code in the BLOB, launches an svchost.exe process and injects to it.


Usually, svchost is launched by services.exe, so the action done by PlugX could be used as a trigger for investigation.


Svchost injection is not new — in fact, Trickbot and other malware variants use this technique.


The difference between Trickbot and PlugX is that Trickbot is much easier to detect.


Trickbot’s binary, which is not whitelisted, does the injection; in PlugX’s case, a normal process that is possibly whitelisted, does the injection.


It is possible for EPP behavior-monitoring features to allow the action of the whitelisted process to go through.


This gives the attacker access to a RAT running inside a normal process.


A unique way of launching tools


Our investigation shows that the attacker used other tools during the attack.


The tools used varied from network scanners to account harvesters.


The simplest way of using these tools is to have the injected code in svchost download, drop, and execute the tools.


Figure 2.


A straightforward approach to launching a malicious tool     The approach above


, although simple, could potentially generate a lot of suspicious telemetry events –  svchost.exe suddenly launching an unknown application could trigger alerts.


To avoid this, the attacker chose a different approach.


For every tool that needs to be run, it creates three things:   The auxiliary tool file <filename>.bat file Cmd.exe with a schtasks.exe command to create a scheduled task to run the batch file above  Instead of directly launching the auxiliary tool, it makes use of a scheduled task that runs the batch file that, in turn, executes the tool.


The attacker’s usage of a tool can be divided into two separate events: the dropping of the tool by the svchost.exe process that runs the malicious code and the execution of the tool via the scheduled task.


Figure 3. A diagram showing the dropping of the auxiliary tool


If the creation of the tool, batch file, and scheduled task is disregarded, it would seem that there is no connection between PlugX and the execution of the auxiliary tool.


However, a deeper investigation proved otherwise.


Figure 4.


Launching the auxiliary tool via the scheduled task     Scheduled tasks are usually associated with persistence or privilege escalation, which is not the case in this incident.


Having the scheduled task run only once removes the notion of persistence.


Meanwhile, having the same user account launch the PlugX process and the auxiliary tool shows that the scheduled task is not for privilege escalation.


One possible reason why the attacker chose this technique is to make analysis and forensics, such as via EDR, more difficult.


The disjoint between the dropping and the execution of the auxiliary tool might cause problems in EDR's rendering of RCA graphs, specifically in providing important information about the attack.


Security analysts will have to rely on telemetry data to provide a more complete picture of said attack.


In this incident, the attacker used a specific tool to gather information kept by the organization.


However, the attacker was able to delete it before we were able to get our hands on the tools used for investigation purposes.


An analysis of these tools could be used to better understand what is happening or what has happened in the environment.


Whenever a tool is used, the attacker deletes it from the disk as soon as it has done its purpose – which usually does not last for more than 15 minutes.


This means that acquiring the tools used would be more difficult.


For the attacker, immediately deleting the tool once it performs its intended purpose means being able to extend its shelf life.


What enterprises and organizations should look out for In incidents like this, wherein the attacker makes sure that the tools used are not detected, threat hunting is a good weapon to have for defense.


Sifting through suspicious events and trying to piece them together to understand what has transpired could help identify such attacks.


Based on our investigation of this specific attack, we provide helpful tips for enterprises and organizations to spot PlugX and lateral movement in their environments.


How to identify PlugX PlugX’s use of a normal file makes it hard for antivirus (AV) or EPP to detect it.


Threat hunters can use this to possibly identify other machines that have PlugX installed: Using attributes that could identify the normal file, such as the hash and the digital signer, a sweeping task could be carried out to identify instances of the normal file.


Chances are, the normal file that loads the rest of PlugX uses a file name that is different from what it normally uses or is in a location where it is not usually found.


For example, Microsoft’s outlook.exe is usually found in the Program Files directory.


Finding a normal outlook.exe in the Windows directory makes it suspicious.


Finding such entries that stand out could help identify how wide the infection is.


How to spot lateral movement


In this particular attack, we observed that to perform lateral movement, the attacker mapped Windows admin shares and used remotely created scheduled tasks to launch malware.


Both events never or rarely happened in the victim’s environment.


The importance of looking into anomalous events


When identifying PlugX and lateral movement techniques utilized in attacks, it’s important to be able to determine anomalous events.


It was relatively easy for us to flag the events related to the breach because they were anomalies; after looking into these anomalies, we were able to map them out to known techniques that attackers previously used.


Keeping an eye on anomalous events could help detect incidents earlier.


In order to have effective visibility and correlation at all times, enterprises need to have an integrated view of all of their interconnected security solutions.


Automated protection and efficient threat hunting, investigation, and response, such as that provided by Trend Micro XDR, will help ensure that enterprises are secured from advanced threats.


Trend Micro Solutions Trend Micro’s comprehensive XDR solution applies the most effective expert analytics to the deep data sets collected from Trend Micro solutions across the enterprise — including email, endpoints, servers, cloud workloads, and networks — making faster connections to identify and stop attacks.


Powerful artificial intelligence (AI) and expert security analytics correlate data from customer environments and Trend Micro’s global threat intelligence to deliver fewer, higher-fidelity alerts, leading to better, early detection.


One console with one source of prioritized, optimized alerts supported with guided investigation simplifies the steps needed to fully understand the attack path and impact on the organization.


Tags  Articles, News, Reports | APT & Targeted Attacks | Research


We noticed a server hosting both a HyperBro sample and a malicious Mach-O executable named “rshell.”


HyperBro is a malware family used by Iron Tiger (also known as Emissary Panda, APT27, Bronze Union, and Luckymouse), an advanced persistent threat (APT) group that has been performing cyberespionage for almost a decade, and there have been no reports of this group associated with a tool for Mac operating systems (OS).


We analyzed the Mach-O sample and found it to be a new malware family targeting the Mac OS platform.


We also eventually found samples compiled for the Linux platform that belongs to the same malware family.


We noticed that a chat application named MiMi retrieved the rshell executable, an app we came across recently while investigating threat actor Earth Berberoka.


We noticed Iron Tiger controlling the servers hosting the app installers of MiMi, suggesting a supply chain attack.


Further investigation showed that MiMi chat installers have been compromised to download and install HyperBro samples for the Windows platform and rshell samples for the Mac OS platform.


While this was not the first time the technique was used, this latest development shows Iron Tiger’s interest in compromising victims using the three major platforms: Windows, Linux, and macOS.


Infection vector MiMi (mimi = 秘密  = secret in Chinese) is an instant messaging application designed especially for Chinese users, with implementations for major desktop and mobile operating systems: Windows, macOS, Android, and iOS.


The desktop versions are developed with the help of ElectronJS framework, which is a cross-platform framework based on Node.js, allowing the developers to create applications with HTML, Javascript (JS), and CSS.


We already came across an abuse of this application during the Earth Berberoka investigation.


However, compared to Earth Berberoka’s routine wherein the threat actor set up a fake website to deliver a malicious chat application, in this instance Iron Tiger compromised the server hosting the legitimate installers for this chat application for a supply chain attack.


Contrary to the fake website, the links to the mobile versions of the application for Android and iPhone worked.


Also, we could not find anything malicious in the latest Windows installer.


In June, we were able to download the macOS installer for the 2.3.2 version of MiMi chat and verified it as genuine.


After downloading it again later, we found that the installer was replaced with a malicious version retrieving the rshell sample.


This was proof that the attackers had direct access to the installers‘ host server, and that they were monitoring the versions published by the MiMi app developers in order to quickly insert a backdoor.


Figure 1. Downloaded installer before (left) and after (right) malware embedding


In this case, we can see that it took an hour and a half for the attackers to modify the legitimate installer and add malicious code to it.


For older versions, it took the attackers one day to inject its modifications.


The modification occurs in the electron-main.js file, which contains a block of code beginning with “eval(function(p,a,c,k,e,d)”, suggesting we are dealing with Dean Edwards packer.       Figure 2. Malicious Javascript code inserted into 2.3.2.dmg targeting macOS      Figure 3. Deobfuscated malicious Javascript code


Once deobfuscated, we saw that the inserted code downloads rshell from the IP address 139[.]180[.]216[.]65 and executes it once run on the macOS platform.


The delivered rshell malware is a new family we will discuss in a later section.


After looking at previous versions of this installer, we found that the first compromised version was 2.3.0, built on May 26, 2022, while the previous version (2.2.10, published on May 6, 2022) was clean.


This led is to our first assumption that Iron Tiger had access to the Mimi chat developer's backend between the two dates in May.


However, a further look at our telemetry revealed older installers that have been compromised, this time aimed at Windows OS.


Version 2.2.0 and 2.2.1 (both built on November 23, 2021), had similar additions to the electron-main.js file.


Figure 4. Malicious Javascript code inserted into 2.2.0.exe targeting Windows OS      Figure 5.


Deobfuscated malicious JavaScript code from 2.2.0.exe     We saw that one executable, one dynamic link library (DLL), and one binary file were being downloaded into the temporary directory before running the executable.


This is the typical way that this threat actor loads its files, exploiting DLL side-loading vulnerabilities in legitimate and usually signed executables.


In this case, the exploited executable belongs to the DESlock+ product, as described last year when we analyzed another Iron Tiger campaign, using malware HyperBro.


Malware analysis rshell


The rshell executable is a standard backdoor and implements functions typical of similar backdoors:  Collect OS information and send it to command and control (C&C) server Receive commands from the C&C server to execute Send command execution results back to the C&C  We found multiple samples of this particular backdoor, with some of them in the Mach-O format (macOS platform), while others were in the ELF format (Linux platform).


The oldest sample we found was uploaded in June 2021, with the first victim reported in mid-July 2021.


The OS information collection routine gathers the following information:  GUID: (randomly generated guid, stored in /tmp/guid) computer name: uname (nodename)


IP addresses: (getifaddrs) message type: login username: _getpwuid (pw_name) version: uname (release)  Once collected, the backdoor “packs” them into a Binary JSON (BSON) message and sends it over TCP to the C&C in clear (unencrypted) form.


Figure 6. Deserialized BSON packet (and displayed as JSON) with login message containing OS information     The message received from the C&C is also in BSON format and contains the following fields:      Table 1. Type and subtype of packets received from the C&C Type Subtype


Explanation


Cmd Init Start new shell Cmd close


Kill shell Cmd data


Commands to execute in shell File Init


List root / directory File Dir List directory


File down Prepare file for downloading File read Read file (transfer bytes) File close


Close file File upload Prepare file for uploading File write Write file (transfer bytes) File Del


Delete file      The client also regularly sends a packet of type ‘keepalive’ to the C&C.


Running the DMG installer on a macOS machine, the user is shown several warnings before the trojanized app is installed and run.


At first, Safari web browser asks the user to allow downloads from the given website.


After choosing “Allow,” downloading, and executing the DMG installer


, another warning message about an unverified developer is displayed.


Figure 7. Unverified developer warning with the “Open” button noticeably missing


To override this warning, the user must open “System Preferences” and “Security & Privacy” tabs and click on “Open Anyway.”      Figure


Security & Privacy tab to allow running apps from unverified developers


Afterward, one more warning about the unverified developer is displayed.


This time, however, the “Open” button appears in the prompt so the application can finally start.      Figure 9.


Unverified developer warning with the “Open” button enabled


We confirmed that both the legitimate and the malicious versions of the chat installer were unsigned, which means the users of MiMi chat were probably used to all these extra steps to finally install the application despite all the macOS watchguards.


HyperBro


The HyperBro malware family has been around since 2017 and has been extensively analyzed.


It was updated in mid-2019, which we described in detail in our Operation DRBControl paper.


The version used in this campaign is no different from what we already described in our previous Iron Tiger investigation.


The only noteworthy element is the Authenticode signature of dlpprem32.dll, which is signed by a (now) revoked certificate belonging to “Cheetah Mobile Inc.”


The said company was formerly known as Kingsoft Internet Software Holdings Limited, wherein during our previous investigation on the group, we already found one HyperBro DLL signed by a certificate belonging to Kingsoft.


Targets


We found 13 different targets while following our sensors‘ data.


The only targeted countries were Taiwan and the Philippines: five targets of HyperBro (four in Taiwan and one in the Philippines).


Meanwhile, we found eight targets for rshell: six in Taiwan, one in the Philippines, and one being in Taiwan and the Philippines.


While we were unable to identify all the targets, these targeting demographics demonstrate a geographical region of interest for Iron Tiger.


Among those targets, we could only identify one of them: a Taiwanese gaming development company.


Interestingly, we found a sample from the Reptile rootkit framework in that same company, as well as network requests to a subdomain that belongs to Earth Berberoka’s infrastructure.


We also noticed network requests from a Taiwanese IT development company to the subdomain trust[.]veryssl[.]org, and the subdomain center.veryssl[.]org is a C&C for one of the rshell samples we found.


This suggests the company could be compromised by the same threat actor.


Timeline  June 2021: Oldest Linux rshell sample found November 2021:


Threat actor modified version 2.2.0 of Windows MiMi chat installer to download and execute HyperBro backdoor May 2021:


Threat actor modified version 2.3.0 of Mac OS MiMi chat installer to download and execute “rshell” backdoor


Attribution and conclusion


We attribute this campaign to Iron Tiger for multiple reasons.


First, the dlpprem32.dll file linked to HyperBro shares certain characteristics (specifically imphash, RICH header) with previous samples already attributed to the group.


Also, the file names involved in the decoding and loading of HyperBro are similar to those we witnessed during our investigation last year.


Second, one of the Linux rshell samples used the IP address 45[.]142[.]214[.]193 as its C&C.


In 2020, that IP address had a particular reverse DNS: nbaya0u2[.]example[.]com.


During our Operation DRBControl investigation, we found a HyperBro sample that had 138[.]124[.]180[.]108 as its C&C. This second IP address had nbaya0u1[.]example[.]com as its reverse DNS.


However, as the rshell sample was found in 2021, we initially did not find this correlation strong enough to attribute the rshellmalware family to Iron Tiger.


Despite the fact that same state-sponsored threat actors tend to share their malware tools (such as gh0st, PlugX, and Shadowpad), this is not the case for HyperBro as far as we know.


The fact that we found this malware being used in this campaign is an additional indicator pointing towards Iron Tiger.


We also found some links to Earth Berberoka.


From one of the victims where we found an rshell sample, we also found a binary belonging to the Reptile rootkit framework, a rootkit identified as part of the arsenal of Earth Berberoka.


We also noticed network communications from this victim to a subdomain of Earth Berberoka, suggesting it could have been previously compromised by this threat actor.


We noticed a different system in the same situation, as well as the network connections to the subdomain trust[.]veryssl[.]org domain name.


One of the rshell samples had center[.]veryssl[.]org as the C&C.


Both findings suggest that those victims could be compromised by both threat actors, or that Earth Berberoka is actually a subgroup of Iron Tiger.


As a reminder, while investigating Earth Berberoka, we found multiple links to Iron Tiger that we detailed in our research.


Indicators of Compromise (IOCs)


You will find the list of IOCs here.


Tags  Malware | Cyber Crime | Privacy & Risks | Cyber Threats | APT & Targeted Attacks | Endpoints | Mobile | Articles, News, Reports


Updated the detection names on January 25, 2018, 9:47 PM PDT


Few cybercrime groups have gained as much notoriety—both for their actions and for their mystique—as the Lazarus group.


Since they first emerged back in 2007 with a series of cyberespionage attacks against the South Korean government, these threat actors have successfully managed to pull off some of the most notable and devastating targeted attacks—such as the widely-reported 2014 Sony hack and the 2016 attack on a Bangladeshi bank—in recent history.


Throughout the Lazarus group's operational history, few threat actors have managed to match the group in terms of both scale and impact, due in large part to the wide variety of tools and tactics at the group’s disposal.


The malware known as RATANKBA is just one of the weapons in Lazarus’ arsenal.


This malicious software, which could have been active since late 2016, was used in a recent campaign targeting financial institutions using watering hole attacks.


The variant used during these attacks (TROJ_RATANKBA.A) delivered multiple payloads that include hacking tools and software targeting banking systems.


We analyzed a new RATANKBA variant (BKDR_RATANKBA.ZAEL-A), discovered in June 2017, that uses a PowerShell script instead of its more traditional PE executable form—a version that other researchers also recently identified.


We identified a number of servers Lazarus used as a backend system for temporarily holding stolen data.


We were able to access this backend, which provided us with valuable information about this attack and its victims.


Around 55% of the victims of RATANKBA’s Powershell version were located in India and neighboring countries.


This implies that the Lazarus group could be is either collecting intelligence about targets in this region, or is at an early stage of planning.


They could have also been performing exercises in preparation for an attack against similar targets.


The majority of the observed victims were not using enterprise versions of Microsoft software.


Less than 5% of the victims were Microsoft Windows Enterprise users, which means that currently, RATANKBA mostly affects smaller organizations or individual users, not larger organizations.


It's possible that Lazarus is using tools other than RATANKBA to target larger organizations.


Lazarus’ backend logs also record victim IP addresses.


Based on a reverse WHOIS lookup, none of the victims can be associated with a large bank or a financial institution.


However, we did manage to identify victims that are likely employees of three web software development companies in India and one in South Korea.


Infection Flow  Figure 1.


RATANKBA Infection Flow RATANKBA is delivered to its victims using a variety of lure documents, including Microsoft Office documents, malicious CHM files, and different script downloaders.


These documents contain topics discussing either software development or digital currencies.


The growth of cryptocurrencies may be a driving force behind the use of cryptocurrency-related lures.


An example of a lure used in a RATANKBA attack can be seen below:  Figure 2. Malicious CHM file used as RATANKBA lure


Once the lure’s recipient opens and executes the file, a backdoor will be dropped into the victim’s system.


This RATANKBA backdoor is what is used to communicate with RATANKBA’s Command-and-Control (C&C) server.


We have observed two initial conversations with the C&C server (all are done via HTTP GET or POST to the server):  HTTP POST to {script}.jsp?action=BaseInfo&u=XXX: Sends the victim information to the backend server HTTP GET to {script}.jsp?action=What&u=XXX: Checks if there are any pending jobs for the backdoor    This means that the backdoor is responsible for both uploading victim information, as well as executing any tasks that the controller has assigned to it, which includes the following:


Killkill: Stops the backdoor’s activities interval: Changes the interval in which the backdoor retrieves jobs; the default interval is set at 120 seconds cmd: Executes shell commands exe:Reflectively injects a DLL downloaded from a specific URL


In addition to the backdoor’s modus operandi, the attackers will use a Microsoft WMI command-line tool to list the compromised system’s running processes, which are sent to the C&C server:  “C:\Windows\system32\cmd.exe” /c “wmic process get processid,commandline,sessionid | findstr SysWOW” “C:\Windows\system32\cmd.exe” /c “wmic process get processid,commandline,sessionid | findstr x86”    Technical Analysis


During our analysis, we collected a copy of the RATANKBA malware’s Lazarus Remote Controller tool.


The remote controller provides a user interface that allows attackers to send jobs to any compromised endpoint.


The controller gives the attackers the ability to manipulate the victims’ host by queueing tasks on the main server.


RATANKBA retrieves and executes the tasks, and retrieves the collected information.


Figure 3. RATANKBA communication diagram


The RATANKBA malware has a control model that does not use real-time communication between the backdoor and the attacker.


Instead, both the remote controller and the backdoor connect to its main communication control server to push or pull pieces of information.


The controller uses a graphical UI interface and can be used to push code to the server, while the backdoor regularly connects to the server to check for pending tasks.


The controller downloads the victim profiles from the server.


If the profiles are already downloaded by the controller, they are deleted from the server side.


The controller can post victim-specific tasks as well as global specific tasks to the server.


Below are the various functionalities of RATANKBA’s controller:


Command Name Function get_time Retrieves the server time delete_inf


Deletes the downloaded victim profiles delete_con Deletes the connection log files if they were already downloaded


Kill: Posts a job to kill the backdoor inject Posts a job for DLL injection Interval Changes the sleep interval Cmd


Posts a job for command shell execution delete_cmd Retrieves the job results and deletes the posted job broadcast_cmd: Posts a job for all the backdoors connecting to the server    Figure 4.


RATANKBA main console interface


Figure 5.


RATANKBA host manipulation console RATANKBA’s controllers use the “Nimo Software HTTP Retriever 1.0” user-agent string for its communication.


The communication protocol format for the controller and backdoor is as follows:  · <domain>/<jsp filename>.jsp?action=<corresponding actions plus additional needed parameters>`


One of most notable changes on the new RATANKBA variant is that the new version was written in Powershell, whereas the original variant was in PE form.


The shift from PE to Powershell makes it more difficult for antivirus solutions to detect.


The screenshot below shows the conversion from C/C++ code to Powershell, while the protocol remained unchanged.


Figure 6. C/C++ version of RATANKBA  Figure 7. Powershell version of RATANKBA Profile of the Attackers


While we do not have any knowledge of who the actual Lazarus attackers are, the data collected from the backend systems gives us some insights into the internet usage patterns of systems likely owned by Lazarus group members.


Clues regarding the profiles of the attackers was also found, including those connected to developers and at least one operator.


All of them appear to be native Korean speakers, or at least have Korean language proficiency that is at the near-native level.


We believe at least one of them also understands Chinese.


We also observed clues that the attackers are interested in cryptocurrencies such as Bitcoin (BTC) and Ant Share (NEO).


One of them transferred shares of NEO at a good market price.


Figure 8. Empty cryptocurrency wallet of the attacker  Figure 9.


An attacker transfers 594 NEO to another wallet, with the money going to a mixer  Figure 10.


An attacker mining Ant Share Defending against RATANKBA


Given Lazarus’ use of a wide array of tools and techniques in their operations, it’s reasonable to assume that the group will continue to use ever-evolving tactics in their malicious activities.


Overall, an organization will need multilayered security strategies, as Lazarus and other similar groups are experienced cybercriminals who employ different strategies to get past organizational defenses.


The impact of this malware can be mitigated with proven mitigation techniques such as routinely scanning the network for any malicious activity to help prevent the malware from entering and spreading through an organization.


In addition, educating employees and other key people in an organization on social engineering techniques can allow them to identify what to look out for when it comes to malicious attacks.


Other mitigation strategies include a multilayered approach to securing the organization’s perimeter, which includes hardening the endpoints and employing application control to help prevent malicious applications and processes from being executed.


Trend Micro™ Deep Security™ provides virtual patching that protects endpoints from threats such as malicious redirections to malware-hosting URLs as well as those that exploit unpatched vulnerabilities.


Trend Micro™ Deep Discovery™ provides detection, in-depth analysis, and proactive response to attacks using exploits and other similar threats through specialized engines, custom sandboxing, and seamless correlation across the entire attack lifecycle, allowing it to detect these attacks even without any engine or pattern update.


A detailed timeline of the Lazarus group's operations can be seen here.


Indicators of Compromise (IoCs): Hashes detected as BKDR_RATANKBA.ZAEL-A  1768f2e9cea5f8c97007c6f822531c1c9043c151187c54ebfb289980ff63d666 6cac0be2120be7b3592fe4e1f7c86f4abc7b168d058e07dc8975bf1eafd7cb25 d844777dcafcde8622b9472b6cd442c50c3747579868a53a505ef2f5a4f0e26a db8163d054a35522d0dec35743cfd2c9872e0eb446467b573a79f84d61761471  f7f2dd674532056c0d67ef1fb7c8ae8dd0484768604b551ee9b6c4405008fe6b      Hashes detected as CHM_DLOADER.ZCEL-A  01b047e0f3b49f8ab6ebf6795bc72ba7f63d7acbc68f65f1f8f66e34de827e49 030b4525558f2c411f972d91b144870b388380b59372e1798926cc2958242863 10cbb5d0974af08b5d4aa9c753e274a81348da9f8bfcaa5193fad08b79650cda 650d7b814922b58b6580041cb0aa9d27dae7e94e6d899bbb3b4aa5f1047fca0f 6cb1e9850dd853880bbaf68ea23243bac9c430df576fa1e679d7f26d56785984 6d4415a2cbedc960c7c7055626c61842b3a3ca4718e2ac0e3d2ac0c7ef41b84d 772b9b873100375c9696d87724f8efa2c8c1484853d40b52c6dc6f7759f5db01 9d10911a7bbf26f58b5e39342540761885422b878617f864bfdb16195b7cd0f5 d5f9a81df5061c69be9c0ed55fba7d796e1a8ebab7c609ae437c574bd7b30b48    Hashes detected as JS_DLOADER.ZBEL-A   8ff100ca86cb62117f1290e71d5f9c0519661d6c955d9fcfb71f0bbdf75b51b3    Hashes detected as X97M_DLOADR.ZBEL-A   972b598d709b66b35900dc21c5225e5f0d474f241fefa890b381089afd7d44ee    Hashes detected as VBS_DLOADR.ZAEL-A   4722138dda262a2dca5cbf9acd40f150759c006f56b7637769282dba54de0cab           Tags  Malware | APT & Targeted Attacks | Endpoints | Cyber Crime | Research | Network


By Fyodor Yarochkin and Vladimir Kropotov (Senior Threat Researchers) Fileless infections are exactly what their namesake says: they're infections that don't involve malicious files being downloaded or written to the system’s disk.


While fileless infections are not necessarily new or rare, it presents a serious threat to enterprises and end users given its capability to gain privileges and persist in the system of interest to an attacker—all while staying under the radar.


For instance, fileless infections have been incorporated in a targeted bot delivery, leveraged to deliver ransomware, infect point-of-sale (PoS) systems, and perpetrate click fraud.


The key point of the fileless infection for the attacker is to be able to evaluate each compromised system and make a decision whether the infection process should continue or vanish without a trace.


The cybercriminal group Lurk was one of the first to effectively employ fileless infection techniques in large-scale attacks—techniques that arguably became staples for other malefactors.


A typical Lurk infection uses browser exploits to deliver non-persistent payloads to potential victims, probing their targets before deploying additional malware.


The infection chain had multiple stages, and was accomplished using bodiless/fileless exploit payloads executed in-memory without additional persistence mechanisms.


No traces were left on affected systems apart from files from the exploit process if the target machine wasn’t interesting to the Lurk operators.


This eponymous lurking behavior would earn them notoriety until their operations were stymied and the perpetrators arrested.


Nine more suspected members of the group were arrested by Russia's Ministry of Internal Affairs on February 8.


Lurk was believed to have siphoned over $45 million from financial organizations, ultimately disrupting the victims' operations, reputation, and bottom line.


How did Lurk evolve from a clique of threat actors to a full-fledged cybercriminal group?


What other techniques were they known for—that other cybercriminals emulated?


How did their operations shift from targeting Russian end users to banks and enterprises?


Our observations of the group were based on code artifacts we analyzed as well as network traffic and URL patterns our intrusion detection systems monitored within several organizations in the Russian Internet segment during Lurk’s five-year campaign.


2011 to early 2012: Humble Beginnings?


Lurk’s web-based attacks were the first signs of their campaigns.


The group already implemented certain mechanisms to prevent AV detection.


Requests during a time period or from a source IP address that didn’t match their preferred distribution area, for instance, would yield a redirect to a third-party site such as Google.


Lurk compromised systems by exploiting web browser vulnerabilities via drive-by download attacks.


Malicious iframe content was injected to high-profile Russian websites, which then served as watering holes to attack unsuspecting end users.


Malvertising and poisoning of content-serving application components, such as memcached cache poisoning, were also part of their traffic redirection methods.


Stealth was already a fixture in their operations.


Before additional malware was served to a victim, the victim machine was first verified and validated with a bodiless payload (executed in memory) that collected information from the compromised machine.


During this time we developed URL-based signatures and used them to detect Lurk-related network traffic.


The signature pattern ^[A-Z0-9]{4}$ was particularly effective in detecting URL patterns employed by Lurk from 2011 to 2013.


The average TTL (Time To Live - the period of time these signatures were effective) for these signatures was two to three months.


The validity time of the signatures also allowed us to identify the group’s software upgrade cycles.


Mid-2012 to mid-2014: Honing the Craft Lurk was most prolific during this period, with its series of URL redirection campaigns in Russia becoming more extensive.


High-profile and high-volume websites were used as intermediate platforms for diverting unknowing visitors to their exploit kit, known as XXX.


Lurk also targeted programmatic advertising infrastructures to increase the scale of their operations.


In February 2012, for instance, the ad server of news agency RIA Novosti, ria[.]ru, was found serving iframe redirects to Lurk’s systems.


The campaign delivered the actual payload only to a select range of IP addresses.


By August 2012, we were able to observe sequences of HTTP requests during and after infection, including command and control (C&C) communication from compromised machines.


When 2014 rolled in, Lurk started exhibiting some patterns similar with the Angler exploit kit.


For example, Lurk increasingly used indexm[.]html as their landing URL pattern; this would also shortly appear in one of Angler’s payloads.


Figure 1. Exploit loading sequence in ria[.]ru (February 2012) Figure 2. [bg].ru (February 2012) found redirecting victims to Lurk’s exploit kit Figure 3. Redirects to the Lurk landing page from adfox[.]ru banner network Figure 4. Malicious iframe content served by tks[.]ru (August 2013)


Lurk’s transition from simple web-browser-exploiting crooks to organized cybercriminals also stood out.


Range and frequency were added to their operations.


Serving criteria were often modified, malicious payloads were often updated.


While Lurk only exploited a certain set of browser vulnerabilities, the exploit code also often changed.


Larger payloads (in number of bytes) typically translated to more functionality being embedded in them, while a smaller change indicated a repacked payload.


True to its namesake, Lurk developed techniques to evade sandbox-based detection.


Aside from serving malicious content only once per IP address, the group limited the range of IP addresses to a subset of targets of interest.


Payload execution was done in multi-tier, chained fashion, and only components delivered at later stages had persistence mechanisms.


The initial bodiless payload was designed to be triggered by the exploit kit shellcode, which performed routine checks in the infected machine.


It would then call back to the group’s C&C server in the form of a Windows executable that, in turn, performs another analysis of the affected system and collected system information, such as installed software packages and their versions, operating system information and so on.


This information was sent back to the C&C server which made decisions on what to do next.


This exhaustive scrutiny, along with the campaign’s objective, determines whether additional modules would be dropped to the system.


Sourcing samples from this was a challenge because the payload’s behavior was mostly influenced by the environment where it was executed.


Acquiring additional modules of the group’s malware, for instance, was nearly impractical if the exploit URLs were loaded in a sandboxed environment.


Malicious content were also often distributed during lunchtime (Moscow’s timezone), and in very short intervals.


We surmise this as their way to hide from automated scraping sandbox detection.


Geographical information of each visiting IP address was actively crosschecked against their regions of interest—Russia and the Commonwealth of Independent States (CIS).


Exploits were also served with higher frequency on certain days of the week: Fridays, and days before public holidays.


Lurk’s infrastructure also exhibited new capabilities.


Among them were distinct patterns used in the HTTP requests and hosting providers.


Based on the hosting providers they used and timing of their hosting migrations, we observed the group compromising websites of software distribution companies and tampered their software installation files.


Their attacks also exploited a number of vulnerabilities that included authentication portal bypass flaws in programmatic ad servers, and those in web servers and other web components.


The mechanisms of redirections were different for each intermediate victim.


Some included ad banner networks or actual sites—while the website content-serving component was poisoned in others.


2012 2013 2014 3dnews[.]ru 3dnews[.]ru 3dnews[.]ru adriver[.]ru adriver[.]ru adfox[.]ru akdi[.]ru adv[.]vz[.]ru auto[.]ru bg[.]ru aif[.]ru avtovzglyad[.]ru com[.]adv[.]vz[.]ru akdi[.]ru drive[.]ru fobos[.]tv gazeta[.]ru glavbukh[.]ru gazeta[.]ru glavbukh[.]ru inosmi[.]ru rian[.]ru infox[.]ru irr[.]ru newsru[.]com klerk[.]ru nalogoved[.]ru target-m[.]ru mn[.]ru news[.]mail[.]ru tks[.]ru newsru[.]com ria[.]ru torrogrill[.]ru rg[.]ru riarealty[.]ru tvrain[.]ru servernews[.]ru nk[.]ru uik-ek[.]ru slon[.]ru rusplt[.]ru ura[.]ru tks[.]ru smotri[.]com slon[.]ru topnews[.]ru sport[.]mail[.]ru vesti[.]ru tvrain[.]ru tks[.]ru


vesti[.]ru utro[.]ua


womanhit[.]ru   Figure 5.


Lurk’s intermediate targets by year 2014 to 2016:


Going Global 2014 was a significant year in Lurk’s history.


A number of high-profile, intermediate victims were still at their fingertips, giving them footholds into the user’s systems.


In a word, they were on a roll.


Why not go global to turn in more profit?


Most of the domains Lurk used during this time were purchased from third-party resellers and paid with WebMoney checks and other anonymous forms of payment available in Russia.


The activities we observed indicated dry runs of malicious injections in banner networks outside Russia and CIS.


In April, we saw Lurk using redirects via mail[.]ru, possibly through malicious injections to its ad server content.


From June to September, Lurk’s landing pages hinted at the group migrating their infrastructure and readying a global campaign.


By the second half of the year, Lurk’s geographical distribution drastically changed.


Russian/CIS-based targets were now sparser, and victims within .ru domains were manually inspected.


Lurk then launched a new URL pattern that served payloads round-the-clock, eschewing pre-filtering of IP address locations in favor of targeting global IP addresses.


We observed systems from other countries connecting to IP addresses operated by Lurk, including Ukraine, U.S., China, Taiwan, Norway, Australia, United Kingdom, Japan, Sweden, Canada, Italy, and South Korea.


We cannot confirm, however, if these countries were actual Lurk targets.


While Lurk favored Java exploits that were used extensively from 2011 to 2012, Flash/swf content was introduced.


An obfuscated Flash file exploiting CVE-2013-5330 was spotted in December 2014.


It was delivered only if the victim’s source IP address (and time) met Lurk’s parameters—otherwise users received a 404 error response.


As mentioned earlier, the XXX Exploit Kit used by Lurk demonstrated several URL-serving patterns and fileless infection capabilities that would later be seen in Angler.


By early 2015, the difference in Lurk and Angler’s activities began to blur—many of their patterns, exploit techniques, and distribution volume overlapped.


Correlation via hosting IP addresses wasn’t very helpful, because Lurk and Angler were often seen hosted on the same service providers.


Lurk also employed dynamically generated domain names for their landing pages.


2016: Lurk’s Downfall Lurk’s active compromise of financial institutions led to a series of enquiries that culminated in the arrest of over 50 individuals involved in its operations across Russia.


The ripple effect led other cybercriminal groups to lie low for the rest of the year.


Other exploit kits like Neutrino and Magnitude either shut down or went private.


By then, Angler’s activities already ceased.


Coincidence?


Based on the similarities of Angler and XXX’s exploit-serving URL patterns and malware delivery techniques (particularly their use of fileless infection) as well as shared infrastructure, we can construe a correlation of both their operations.


In a way, the rise and fall of Lurk also reflected the evolution of the threat landscape.


We can only predict the constant development of seemingly novel and unforeseen techniques for evading traditional security systems, which is exacerbated by how these can become commercially available to other bad guys.


Unfortunately, Lurk is just one of the many cybercriminal groups looking to profit from organizations and end users.


Best Practices Lurk’s story demonstrates the aptitude of cybercriminals for honing in on specific victims and profiting from them.


Whether spying for profit, pilfering credentials, emptying bank accounts, or misinforming an unknowing public, bad guys will progressively develop attacks that can neuter traditional defenses.


These threats pose greater challenges to security and IT administrators in terms of how their organization’s perimeter can be secured.


A multilayered approach is key, along with security-minded practices: apply the latest patches, block malware-hosting sites, implement URL categorization, employ firewalls and IDSs, and foster a culture of security in the workplace.


Defense in depth should also be considered—there are no silver bullets, no single network defense tool that can be used to deal with these threats.


End-user systems can serve as main gateways for attackers, which is why hardening them is critical.


This includes whitelisting and monitoring suspicious applications and processes, as well as well applying least privilege principles on the systems.


The attack surface—which can come in the form of software packages (including their extensions and plugins) that can interact with untrusted components—must also be reduced.


Unused browser plugins and any functionality that lets browsers execute third-party code should be inspected and disabled.


In Lurk’s case, the group favored exploiting vulnerabilities in Flash and Java plugins for web browsers.


To mitigate intrusions, direct internet access to the organization’s internal network should be disabled, and users should be obliged to utilize application proxies instead when accessing external network resources.


This should be especially enforced for HTTP and HTTPS protocols that cybercriminals frequently leverage for their attacks.


URLs and URL content (i.e. mime-types) should be stringently analyzed.


Likewise, all executable content should be considered with a grain of salt—especially if they’ve been downloaded from unknown sources.


Continuously monitoring the network for spikes of suspicious behavior—or those that may first appear as benign—can also help detect intrusion attempts.


For instance, a significant number of machines within the organization’s network suddenly attempting to resolve and connect to a domain name never observed before can indicate a network infection or exploit.


Network detection and endpoint security systems can also help notify system administrators and direct them to artifacts left by successful or failed exploit attempts.


End users must ultimately keep pace: regularly update the system, and take caution against random or socially engineered links from suspicious or spoofed emails and websites.


Trend Micro Solutions Trend Micro™ Deep Security™ and Vulnerability Protection provide virtual patching that protects endpoints from threats such as fileless infections and those that abuse unpatched vulnerabilities.


OfficeScan’s Vulnerability Protection shields endpoints from identified and unknown vulnerability exploits even before patches are deployed.


Trend Micro™ Deep Discovery™ provides detection, in-depth analysis, and proactive response to attacks using exploits through specialized engines, custom sandboxing, and seamless correlation across the entire attack lifecycle, allowing it to detect similar threats even without any engine or pattern update.


A list of pertinent Indicators of Compromise (IoCs) can be found in this appendix.


Updated as of February 6, 2017, 10:05 PM (UTC-7): We updated to include observed systems from other countries that connected to IP addresses operated by Lurk.


Updated as of February 9, 2017, 1:44 AM (UTC-7): We updated to include the latest news about the arrests of suspected members of the group.        Tags  APT & Targeted Attacks | Malware | Endpoints | Research


One of the largest meat suppliers in the world, JBS was recently affected by a ransomware attack.


In a statement released on May 30, 2021, the company said that the attack affected some of its servers that support its North American and Australian IT Systems.


According to a report by Bloomberg, JBS USA had shutdowns at its nine beef plants on Tuesday, May 31.


The company's meatpacking facilities across the US have also experienced some level of disruptions to operations, said an official with the United Food and Commercial Workers International Union.


Meanwhile, JBS's slaughter operations in 47 sites across Australia were also disrupted.


David Littleproud, Australia's agriculture minister, said that the attack had locked up the systems JBS used for quality assurance in meat processing.


On Tuesday, the Brazilian meat supply giant said that while the ransomware attack affected its Australia and North America operations, their systems were slowly being restored from backup.


The FBI, the Australian, and Canadian authorities have been helping JBS to locate the attackers, which are believed to be in Russia.


In a statement released on June 2, the FBI attributed the attack to REvil and Sodinokibi.


The bureau added that they are "working diligently to bring the threat actors to justice"


According to Principle Press Secretary Karine Jean-Pierre, the White House also is working directly with the Department of Agriculture.


The White House has also reached out to various meat processors in the US, ensuring that they are aware of the situation.


The JBS cyber attack comes just three weeks after Colonial Pipeline, the US's largest pipeline system, was targeted in a ransomware attack.


Earlier in May, Ireland's Health Service Executive (HSE) was also hit by a ransomware attack, which continues to result in major issues.


Twenty days later, HSE continues to face IT system difficulties, causing delays in some of its services.


With ransomware and various cyber-attacks continually targeting critical infrastructure and enterprises, the need for stronger and more robust cybersecurity is important more than ever.


Executives and decision-makers must understand that cybersecurity is not just an IT issue but a major element that affects the entire organization and its operations.


At the forefront of cybersecurity solutions, Trend Micro offers extensive forward-looking research and studies, aiming to help enterprises and decision-makers safeguard their businesses and infrastructures.


To learn more about keeping your enterprise secure, read "Best Practices for Securing Smart Factories: Three Steps to Keep Operations Running" which explores security issues faced by smart factories and defense strategies that can be used.


Tags  Latest News | ICS OT | APT & Targeted Attacks | Ransomware | Articles, News, Reports | Cyber Threats


At least 30,000 organizations are already thought to have been attacked in the US, but the number may be much larger globally — giving the hackers remote control over victims’ systems.


In our most recent check of Shodan, there are still around 63,000 exposed servers vulnerable to these exploits.


Applying the available patches should be a top priority, or disconnect any vulnerable servers you may be running if you can’t patch immediately.


At this time, anyone with an Exchange server needs to take investigative steps to check for signs of compromise.


We fully echo the recommendations from Microsoft and others.


In addition, existing XDR customers can use pre-built queries in Trend Micro Vision One to search for signs of the attack in their environment.


These queries can be found in our Knowledge Base article, along with details on the added detections and protections that customers can leveraged across all security solutions.


What happened?


The attacks have been traced back to January 6, 2021, when a new threat group subsequently labelled “Hafnium” by Microsoft began exploiting four zero-day bugs in Microsoft Exchange Server.


The group is using virtual private servers (VPS) located in the US to try to hide its true location.


Microsoft issued emergency out-of-band patches last week, saying at the time:  “In the attacks observed, the threat actor used these vulnerabilities to access on-premises Exchange servers which enabled access to email accounts, and allowed installation of additional malware to facilitate long-term access to victim environments.”


If chained, the vulnerabilities could be exploited to allow attackers to authenticate as the Exchange server, run code as System and write a file to any path on the server.


After exploiting the four bugs, Hafnium is said to deploy web shells which allow the group to steal data and perform additional malicious actions to further compromise their targets.


This could include deploying ransomware to victim organizations.


Both the White House and the US Cybersecurity and Infrastructure Security Agency (CISA) are extremely concerned about the far-reaching consequences of the campaign.


CISA ordered government agencies to patch now or disconnect their on-premises Exchange servers.


There is also a possible connection to the Chopper ASPX web shell research we published back in January 2021.


Trend Micro Research is analyzing further how the campaigns may be related, and whether additional related campaigns may be underway.


Am I impacted?


In Microsoft’s initial assessment it claimed that Hafnium has previously targeted organizations in sectors such as infectious disease research, legal, higher education, defense, policy think tanks and NGOs.


However, there are suggestions that the latest expansive wave of attacks may be the work of other threat actors.


Whatever the source, former CISA boss Chris Krebs warns that SMBs, education sector organizations, and state and local governments may be disproportionately affected as these often have fewer resources to spend on security.


If you run on-premises Exchange Servers, here is how to check if you’re impacted:


Scan your Exchange Server logs with the Microsoft detection tool to check for compromise.


Run a manual sweep with Trend Micro Vision One for the known Indicators of Compromise (IoCs) associated with this campaign.


What happens next?


If you’ve run a scan and found that your environment hasn’t yet been compromised, and you haven’t yet patched, apply the patches released by Microsoft as soon as possible.


If you run the scan using Microsoft’s tool and see evidence that an attacker may have exploited these vulnerabilities in your environment, you are now in incident response mode.


But the approach you take may depend on your in-house resources and situation.


Here’s our advice for SMB and enterprise organizations.


If you don’t have an in-house security team, contact your security vendor or MSP for support.


If you have an in-house incident response team, they will work to identify next steps.


Do not re


image any machines until after a forensic scan has been done to ensure you’ve preserved any IoCs.


Contact your legal team to discuss breach notification requirements.


For more information on Trend Micro’s detections and added protections specific to this campaign, please see this Knowledge Base article, which will be updated as more information is learned: https://success.trendmicro.com/solution/000285882.        Tags  Latest News | APT & Targeted Attacks | Exploits & Vulnerabilities | Articles, News, Reports | Data center


By developing a common language to arm analysts with a standard to describe attacks, MITRE ATT&CK has become a critical knowledgebase for cyber defenders, ultimately improving security efficiency and response time.


The annual MITRE Evaluation compares industry-wide innovation to deliver the solutions necessary to detect and respond to the evolving threat landscape.


The evaluation offers cybersecurity solution buyers and customers with an unbiased option to evaluate security products to arm themselves against the latest advances from attackers based on their areas of greatest need.


This year’s evaluation saw vendors detect and respond to tactics, techniques, and procedures (TTPs) from two emulated adversary scenarios that are broadly defining modern ransomware today — Wizard Spider, a cybercriminal extortion gang, and Sandworm, a disruptive threat group focused on data destruction.


Critical evaluation categories include:  Analytic Coverage: Enriched detections to deliver greater context to investigation by adding ATT&CK TTP mapping, improving triage for analysts.


Visibility: Clear availability of analytic or telemetry information to enable faster response time for incident response and threat hunting.


Protection: Threat prevention and blocking to deflect risk early-on and optimize holistic security team efforts.


Trend Micro’s Unified Cybersecurity Platform Recorded Impressive Results For the third year in a row Trend Micro Vision One proved itself as an invaluable tool for security teams.


It tested against simulated breaches that included 109 total attack steps.


Detection: Delivered on 19/19 attack steps in the evaluation, for 100% detection.


Visibility: Provided clear visibility on 105 out of 109 attack methods providing 96.33% coverage.


Protection: Top ranking in the protection category, offering 100% prevention.


Linux: Top performance among leading vendors, detecting and preventing 100% of attacks against the Linux host.


Trend Micro recommends customers prioritize Linux coverage considering its popularity as the most used OS in cloud-native applications.


Trend Micro Vision One correlates intelligence across email, endpoints, servers, networks and cloud workloads to generate fewer but higher fidelity alerts for security operations (SecOps) teams.


The increase in efficiency simplifies investigations, optimizes SecOps productivity, and accelerates remediation to stop threat actors in their tracks before they have a chance to cause lasting damage.


Vision One connect the dots in security incidents, showing how they might be related and highlighting indicators of compromise similar to known attack groups and types.


To read a full copy of the MITRE Engenuity ATT&CK Evaluation for Trend Micro Vision One report, please visit: https://resources.trendmicro.com/MITRE-Attack-Evaluations.html        Tags  Cloud | Latest News | Cyber Threats | APT & Targeted Attacks | Endpoints | Network | Articles, News, Reports


We uncovered a recent activity involving the notorious online credit card skimming attack known as Magecart.


The attack, facilitated by a new cybercrime group, impacted 201 online campus stores in the United States and Canada.


We started detecting the attacks against multiple campus store websites on April 14, during which the sites were injected with a malicious skimming script (detected by Trend Micro as Trojan.JS.MIRRORTHEIF.AA) at their payment checkout pages.


The skimming script can scrape credit card information, as well as personal details entered on the payment page.


The stolen information is consequently sent to a remote server.


After looking into this attack, we learned that the attackers compromised PrismWeb, which is an e-commerce platform designed for college stores by company PrismRBS, a subsidiary of Nebraska Book Company.


The attacker injected their skimming script into the shared JavaScript libraries used by online stores on the PrismWeb platform.


We confirmed that their scripts were loaded by 201 campus book and merchandise online stores, which serves 176 colleges and universities in the U.S. and 21 in Canada.


The amount of payment information that was stolen is still unknown.


We disclosed our findings to PrismRBS.


The company has since released an official statement regarding the skimming attack: "On April 26, 2019, PrismRBS became aware that an unauthorized third-party obtained access to some of our customers’ e-commerce websites that PrismRBS hosts.


Upon learning of this incident, we immediately took action to halt the current attack, initiated an investigation, engaged an external IT forensic firm to assist in our review, notified law enforcement and payment card companies.


Our investigation is ongoing to determine the scope of the issue, including who and what information may have been impacted.


Based on our review to date, we have determined that an unauthorized party was able to install malicious software designed to capture payment card information on some of our customers’ e-commerce websites.


We are proactively notifying potentially impacted customers to let them know about the incident, the steps we are taking to address the situation, and steps they can take to protect their end users.


We deeply regret any concern or frustration this incident may cause.


Protecting the security and privacy of information remains a top priority.


We are taking steps to further strengthen the security of our systems, including enhanced client-side and back-end monitoring tools and a comprehensive end-to-end audit of our systems.


Once our investigation concludes, we will be providing our customers with additional information and guidance."


Since we can’t connect the said attack to any previous Magecart groups — even if the attack shared some similar characteristics with a few of them — we labeled this new group “Mirrorthief”.


Figure 1. Mirrorthief attack chain  Figure 2.


Payment page of PrismWeb online store loads Mirrorthief’s skimming script


Figure 3. Mirrorthief injection on PrismWeb checkout payment’s library How Mirrorthief performs their skimming activities


On April 14, the attackers injected a script to the payment checkout libraries used by the PrismWeb platform.


The location of injected payment checkout libraries on affected online stores were:  hxxps://[online store domain]/innerweb/v4.0/include/js/checkout_payment[.]js hxxps://[online store domain]/innerweb/v3.1/include/js/checkout_payment[.]js  The injected script forged the Google Analytics script format, but loaded a different script from the attackers’ server.


The loaded script is the main script that steals the payment information.


Unlike many web skimmers, which are designed to collect information from many kinds of e-commerce payment pages in general, the skimmer that the Mirrorthief group used was designed specifically for PrismWeb’s payment page.


The skimmer collects data only from HTML elements with the specific IDs on PrismWeb’s payment form.


The stolen credit card information includes card number, expiry date, card type, card verification number (CVN), and the cardholder’s name.


The skimmer also steals personal information like addresses and phone numbers for billing.


Once the user has finished filling in the payment form and clicked on the payment review, the skimmer copies the targeted information into JavaScript Object Notation (JSON) format data and encrypts it with AES encryption and Base64 encoding.