Feed aggregator

ISC Stormcast For Wednesday, April 24th, 2024 https://isc.sans.edu/podcastdetail/8952

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

A while back I got an email from Perry, one of our readers who was having a problem using my cvescan script, which I covered in a 3 part story back in 2021:

• https://isc.sans.edu/forums/diary/Using+the+NIST+Database+and+API+to+Keep+Up+with+Vulnerabilities+and+Patches+Part+1+of+3/26958/
• https://isc.sans.edu/forums/diary/Using+the+NIST+Database+and+API+to+Keep+Up+with+Vulnerabilities+and+Patches+Playing+with+Code+Part+2+of+3/26964/
• https://isc.sans.edu/forums/diary/Using+the+NVD+Database+and+API+to+Keep+Up+with+Vulnerabilities+and+Patches+Tool+Drop+CVEScan+Part+3+of+3/26974/

The problem was simple, the script had just stopped working.  The NVD API version 1.0 had been retired in Dec 2023, and of course I had no idea.  A quick visit to their website got me the details of this change:

• https://nvd.nist.gov/general/news/nvd-program-transition-announcement
• https://nvd.nist.gov/general/news/api-20-announcements

Anyway - this turned into a simple enough set of changes for my script, but some fundamental changes to the API itself.  Full docs for the API start here:

• https://nvd.nist.gov/developers

First, they moved from an open restful API to one that (they say) requires an API key (more on this later).  This takes care of change notifications in future, because you have to register to get a key.  Watch your spam folder, Outlook helpfully placed the email with the registration link in it in my Junk Email folder. The original call in the NVD 1.0 API to collect CVE's for a specific product IOD (CPE) is: $request = "https://services.nvd.nist.gov/rest/json/cves/1.0?modStartDate=" + $StartDate + "&cpeMatchString=" + $app.cpe $CVEs = (invoke-webrequest $request | ConvertFrom-Json).result.CVE_items.cve.CVE_data_meta.id Similarly, the NVD 1.0 API call to collect the metadtaa for a specific CVE: $request = "https://services.nvd.nist.gov/rest/json/cve/1.0/" + $CVE.CVE $cvemetadata = (invoke-webrequest $request) | convertfrom-json In the version 2 API, let's construct an example call, looking for CVE's in Windows 10.  For a review of CPE's, check out the first 3 parts of this story.  I often "feed" CVEScan by collecting CPE's using nmap for instance.  Anyway, back to constructing the request: $cpematchstring = "cpe:2.3:o:microsoft:windows_10:1607:*:*:*:*:*:*:*" $request = "https://services.nvd.nist.gov/rest/json/cves/2.0?cpeName=" + $cpematchstring Now let's make the call and look at the fields we get back: (invoke-webrequest $request | ConvertFrom-Json) | gm    TypeName: System.Management.Automation.PSCustomObject Name            MemberType   Definition ----            ----------   ---------- Equals          Method       bool Equals(System.Object obj) GetHashCode     Method       int GetHashCode() GetType         Method       type GetType() ToString        Method       string ToString() format          NoteProperty string format=NVD_CVE resultsPerPage  NoteProperty int resultsPerPage=2000 startIndex      NoteProperty int startIndex=0 timestamp       NoteProperty string timestamp=2024-04-23T17:40:15.370 totalResults    NoteProperty int totalResults=2574 version         NoteProperty string version=2.0 vulnerabilities NoteProperty Object[] vulnerabilities=System.Object[] Now let's look at the vulnerability list, picking just a random item in the list: $v = (invoke-webrequest $request | ConvertFrom-Json).vulnerabilities $v[7].cve id               : CVE-2016-0170 sourceIdentifier : secure@microsoft.com published        : 2016-05-11T01:59:10.027 lastModified     : 2018-10-12T22:11:24.817 vulnStatus       : Modified descriptions     : {@{lang=en; value=GDI in Microsoft Windows Vista SP2, Windows Server 2008 SP2 and R2 SP1, Windows 7                    SP1, Windows 8.1, Windows Server 2012 Gold and R2, Windows RT 8.1, and Windows 10 Gold and 1511                    allows remote attackers to execute arbitrary code via a crafted document, aka "Windows Graphics                    Component RCE Vulnerability."}, @{lang=es; value=GDI en Microsoft Windows Vista SP2, Windows Server                    2008 SP2 y R2 SP1, Windows 7 SP1, Windows 8.1, Windows Server 2012 Gold y R2, Windows RT 8.1 y                    Windows 10 Gold y 1511 permite a atacantes remotos ejecutar c??digo arbitrario a trav??s de un                    documento manipulado, tambi??n conocido como "Windows Graphics Component RCE Vulnerability".}} metrics          : @{cvssMetricV30=System.Object[]; cvssMetricV2=System.Object[]} weaknesses       : {@{source=nvd@nist.gov; type=Primary; description=System.Object[]}} configurations   : {@{nodes=System.Object[]}} references       : {@{url=http://packetstormsecurity.com/files/137096/Microsoft-Windows-gdi32.dll-ExtEscape-Buffer-Over                    flow.html; source=secure@microsoft.com}, @{url=http://www.securityfocus.com/bid/89864;                    source=secure@microsoft.com}, @{url=http://www.securitytracker.com/id/1035823;                    source=secure@microsoft.com},                    @{url=https://docs.microsoft.com/en-us/security-updates/securitybulletins/2016/ms16-055;                    source=secure@microsoft.com}} There's no need for a second call, all the NVD metadata is in the returned data for that first call!  You can just keep parsing as deep as you want until you get the exact fields that you want!  For instance, if we just want the CVE list: $cvelist =  $v.id $cvelist CVE-2013-3900 CVE-2015-6184 CVE-2016-0088 ... and so on Or if you wanted the CVE list and the last modified date: $datelist =  (invoke-webrequest $request | ConvertFrom-Json).vulnerabilities.cve | select id,lastModified $datelist id             lastModified --             ------------ CVE-2013-3900  2022-11-02T15:15:43.850 CVE-2015-6184  2018-10-12T22:10:41.470 CVE-2016-0088  2018-10-12T22:11:00.707 CVE-2016-0089  2018-10-12T22:11:00.910 .. and so on Sticking with our favourite item lucky 7, the description would be: $v[7].cve.descriptions[0].value GDI in Microsoft Windows Vista SP2, Windows Server 2008 SP2 and R2 SP1, Windows 7 SP1, Windows 8.1, Windows Server 2012 Gold and R2, Windows RT 8.1, and Windows 10 Gold and 1511 allows remote attackers to execute arbitrary code via a crafted document, aka "Windows Graphics Component RCE Vulnerability." To get exploitability and import scores for both version 2 and version 3 of the CVSS Metric: $v[7].cve.metrics.cvssmetricv2 ource                  : nvd@nist.gov type                    : Primary cvssData                : @{version=2.0; vectorString=AV:N/AC:M/Au:N/C:C/I:C/A:C; accessVector=NETWORK;                           accessComplexity=MEDIUM; authentication=NONE; confidentialityImpact=COMPLETE;                           integrityImpact=COMPLETE; availabilityImpact=COMPLETE; baseScore=9.3} baseSeverity            : HIGH exploitabilityScore     : 8.6 impactScore             : 10.0 acInsufInfo             : False obtainAllPrivilege      : False obtainUserPrivilege     : False obtainOtherPrivilege    : False userInteractionRequired : True   $v[7].cve.metrics.cvssmetricv2.impactscore 10.0 $v[7].cve.metrics.cvssmetricv2.exploitabilityscore 8.6 And for v3: $v[7].cve.metrics.cvssmetricv30 source              : nvd@nist.gov type                : Primary cvssData            : @{version=3.0; vectorString=CVSS:3.0/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H; attackVector=NETWORK;                       attackComplexity=LOW; privilegesRequired=NONE; userInteraction=REQUIRED; scope=UNCHANGED;                       confidentialityImpact=HIGH; integrityImpact=HIGH; availabilityImpact=HIGH; baseScore=8.8;                       baseSeverity=HIGH} exploitabilityScore : 2.8 impactScore         : 5.9   $v[7].cve.metrics.cvssmetricv30.exploitabilityscore 2.8 $v[7].cve.metrics.cvssmetricv30.impactscore 5.9   $v[7].cve.metrics.cvssmetricv30.cvssdata version               : 3.0 vectorString          : CVSS:3.0/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H attackVector          : NETWORK attackComplexity      : LOW privilegesRequired    : NONE userInteraction       : REQUIRED scope                 : UNCHANGED confidentialityImpact : HIGH integrityImpact       : HIGH availabilityImpact    : HIGH baseScore             : 8.8 baseSeverity          : HIGH   $v[7].cve.metrics.cvssmetricv30.cvssdata.basescore 8.8 Going back to collect the URL references: $v[7].cve.references | fl   url    : http://packetstormsecurity.com/files/137096/Microsoft-Windows-gdi32.dll-ExtEscape-Buffer-Overflow.html source : secure@microsoft.com url    : http://www.securityfocus.com/bid/89864 source : secure@microsoft.com url    : http://www.securitytracker.com/id/1035823 source : secure@microsoft.com url    : https://docs.microsoft.com/en-us/security-updates/securitybulletins/2016/ms16-055 source : secure@microsoft.com So, for just the URLs: $v[7].cve.references.url http://packetstormsecurity.com/files/137096/Microsoft-Windows-gdi32.dll-ExtEscape-Buffer-Overflow.html http://www.securityfocus.com/bid/89864 http://www.securitytracker.com/id/1035823 https://docs.microsoft.com/en-us/security-updates/securitybulletins/2016/ms16-055 The API key? So far I haven't needed it.  This may just be a way of the NVD folks getting a list of the developers that use their API (with email addresses), so that they can tell us in advance when API 2.1 or 3.0 is about to be released(?)  If it is, I'm 100% OK with that, I WANT to know in advance if someone else is going to break my code! As always, I'll update my cvescan script in the next few days to match the new API, you can find it in my github then at https://github.com/robvandenbrink If you have used external APIs in your code, then had the API unexpectedly change on you and bite you, please use our comment form and share the details (if your NDA permits?) ===============
Rob VandenBrink
rob@coherentsecurity.com (c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

Mañana 25 de Abril estaremos Iker Casillas y yo en la Universidad UNIR de Miami con un evento de jornada de mañana centrada en tecnología, donde hablaremos de Ciberseguridad e IA, y de SportTech con el acuerdo que tenemos entre Wayra y SportBoost para invertir en Startup Tecnológicas en este área.
Figura 1: UNIR Innovation Day Miami 2024: Ciberseguridad & IA+ Sport Tech (25 de Abril). Presencial & Online
La sesión tendrá lugar en Miami, así que si estás en Estados Unidos por esa zona, estás más que invitado a pasarte. El programa del evento, es el siguiente, donde como podéis ver tendremos un debate al final, en el que se podrán hacer preguntas a los ponentes del panel, y antes habrá dos charlas de ciberseguridad, IA, y la seguridad y protección del tiempo con MyPublicInbox.
Figura 2: Programa del Miami Innovation Day
Si quieres asistir a este evento de forma PRESENCIAL en Miami, y estar con Iker Casillas y conmigo allí, debes registrarte antes a través de este enlace. Estaremos en la Universidad UNIR de Miami, así que te esperamos por allí. El espacio está limitado, porque el auditorio no es muy grande, así que más vale que te des prisa en registrarte.
Figura 3: UNIR Innovation Day Miami 2024: PRESENCIAL
Si no puedes venir presencialmente, pero quieres asistir ONLINE, entonces debes registrarte a través de este otro enlace, y aunque no estarás con nosotros, sí que podrás hacer preguntas y participar de todas las charlas en directo.
Figura 4: UNIR Innovation Day Miami 2024: ONLINE
Por último, para todos los asistentes al evento - tanto presencial como Online -, la UNIR entregará 500 Tempos de MyPublicInbox para que puedas utilizarlos en la plataforma y tener comunicación con Iker Casillas, conmigo, o con cualquier otro perfil público de la plataforma.
Figura 5: Buzón Público de Iker Casillas en MyPublicInbox
Si estás por la zona de Miami, y tienes ganas de venir a vernos, mañana es una oportunidad fantástica para que vengas a conocernos, que Iker Casillas y yo no damos muchos eventos presenciales por la zona, y que se dé esta situación otra vez, va a ser difícil. Y si te gusta el contenido y no estás por la zona, pues presencial es tu opción.
¡Saludos Malignos!
Autor: Chema Alonso (Contactar con Chema Alonso)  


Sigue Un informático en el lado del mal RSS 0xWord
- Contacta con Chema Alonso en MyPublicInbox.com

Enlarge (credit: Getty Images) Hackers abused an antivirus service for five years in order to infect end users with malware. The attack worked because the service delivered updates over HTTP, a protocol vulnerable to attacks that corrupt or tamper with data as it travels over the Internet. The unknown hackers, who may have ties to the North Korean government, pulled off this feat by performing a man-in-the-middle (MiitM) attack that replaced the genuine update with a file that installed an advanced backdoor instead, said researchers from security firm Avast today. eScan, an AV service headquartered in India, has delivered updates over HTTP since at least 2019, Avast researchers reported. This protocol presented a valuable opportunity for installing the malware, which is tracked in security circles under the name GuptiMiner.Read 10 remaining paragraphs | Comments

Enlarge (credit: Getty Images) On Tuesday, Microsoft announced a new, freely available lightweight AI language model named Phi-3-mini, which is simpler and less expensive to operate than traditional large language models (LLMs) like OpenAI's GPT-4 Turbo. Its small size is ideal for running locally, which could bring an AI model of similar capability to the free version of ChatGPT to a smartphone without needing an Internet connection to run it. The AI field typically measures AI language model size by parameter count. Parameters are numerical values in a neural network that determine how the language model processes and generates text. They are learned during training on large datasets and essentially encode the model's knowledge into quantified form. More parameters generally allow the model to capture more nuanced and complex language-generation capabilities but also require more computational resources to train and run. Some of the largest language models today, like Google's PaLM 2, have hundreds of billions of parameters. OpenAI's GPT-4 is rumored to have over a trillion parameters but spread over eight 220-billion parameter models in a mixture-of-experts configuration. Both models require heavy-duty data center GPUs (and supporting systems) to run properly.Read 8 remaining paragraphs | Comments

Phishing threats have reached unprecedented levels of sophistication in the past year, driven by the proliferation of generative AI tools. Transforming how cybercriminals operate, AI advancements are revolutionizing and reshaping the phishing threat landscape. Moreover, this technology has democratized the ability to orchestrate intricate phishing campaigns, making it easier than ever for even beginners to conduct complex and believable phishing attacks. Specifically, this observed shift is enabling novice cybercriminals to launch highly convincing, personalized scams with ease. As a result, organizations now face a myriad of new challenges in protecting their data and systems from the increasing onslaught of phishing attacks. In response, the Zscaler ThreatLabz team has released the 2024 Phishing Report. This report analyzes over 2 billion phishing transactions from 2023, found within the Zscaler cloud, to equip organizations with a clear understanding of the rapidly evolving phishing landscape. Providing insights into the latest trends and tactics used by cybercriminals, the report highlights active phishing campaigns, exposes emerging schemes, and identifies top targets by region, industry, imitated brand, and more. Showcasing real-world examples, ThreatLabz phishing findings underscore the importance of applying constant vigilance and zero trust security strategies. The guidance offered aims to help organizations strengthen their defenses against these evolving phishing techniques.Download the Zscaler ThreatLabz 2024 Phishing Report to gain the knowledge needed to proactively combat the rising wave of new phishing threats. 6 key phishing findingsThe following findings represent a subset of key phishing trend discoveries that shed light on the evolution of phishing tactics. Top phishing trends Phishing attacks surged by 58.2% in 2023 compared to the previous year, reflecting the growing sophistication and reach of threat actors. Voice phishing (vishing) and deepfake phishing attacks are on the rise as attackers harness generative AI tools to amplify their social engineering tactics. Adversary-in-the-middle (AiTM) phishing attacks persist and browser-in-the-browser (BiTB) attacks are emerging as a growing threat. Top phishing targets The US, UK, India, Canada, and Germany were the top five countries targeted by phishing attacks. The finance and insurance industry faced 27.8% of overall phishing attacks, marking the highest concentration among industries and a 393% year-over-year increase. Microsoft remains the most frequently imitated brand, with 43.1% of phishing attempts targeting it. Discover further insights into each of these findings and more in the report. Spotlight on AI-enabled phishing threatsGenAI has undoubtedly proven transformative in turning up productivity across businesses. Yet on the flip side of this transformation is a perilous truth: AI is also turning novice to average threat actors into skilled social engineers and sophisticated phishing attackers.By automating and personalizing various components of the attack process, AI speeds up and refines phishing attacks, making them more sophisticated and difficult to detect. GenAI quickly analyzes public data, such as information about organizations and executives, saving time in reconnaissance for threat actors and enabling more precise targeted attacks. LLM chatbots craft accurate, believable phishing communications and emails by eliminating misspellings and grammar mistakes. GenAI can swiftly generate convincing phishing pages. The ThreatLabz report showcases how ChatGPT created a phishing login page in less than 10 prompts, and provides key indicators to look out for when identifying a phishing page. AI has blurred the line between authentic and fraudulent content, making it all the more challenging to discern phishing schemes from legitimate web pages and digital communication.As ThreatLabz researchers tracked phishing trends throughout 2023, several notable advanced AI tactics also emerged. Among these were the rise of vishing and deepfake phishing, increasingly favored social engineering tactics that use AI-powered impersonation tools. Vishing insightsAdvanced vishing campaigns are gaining popularity globally, leading to substantial financial losses in some cases. In a notable attempt that ThreatLabz thwarted during the summer of 2023, phishing attackers used AI technology to perpetrate a vishing attack by impersonating Zscaler CEO Jay Chaudhry. The report details the sequence of events, serving as a critical reminder for enterprises and employees to stay vigilant against vishing scammers. ThreatLabz anticipates a continued surge in targeted voice phishing campaigns led by groups like Scattered Spider in the next year. As these efforts aim to acquire employee login credentials, it is imperative for organizations to fortify their phishing defenses to prevent unauthorized access and exploitation. Deepfake insightsPhishing attacks involving deepfakes will be one of the most challenging AI-driven cyberthreats. Threat actors now possess the ability to create video content that precisely and accurately replicates faces, voices, and mannerisms. This manipulation has already manifested in concerning ways, such as in the electoral process, where deepfake videos fabricate false narratives or statements from political figures. These videos can sway public opinion, disseminate disinformation, and erode trust in the integrity of the electoral process. As society becomes more and more reliant on digital communication and media consumption, the potential political and life-altering ramifications of deepfake scams will likely extend far beyond the scope of current applications. From financial scams to corporate espionage, the use of deepfake technology poses a significant threat to organizations, individuals, and society at large.Additionally, ThreatLabz observed a rise in QR code scams, recruitment scams, browser-in-the-browser (BitB) attacks, and adversary-in-the-middle (AiTM) attacks. Learn more about each of these schemes in the report. Mitigate phishing risk with zero trustGiven the concerning threat landscape uncovered by this year’s report, how can organizations protect against the latest phishing threats? One definitive solution lies in establishing a foundation of a zero trust architecture. Adapting security strategies to combat new phishing trends and mitigate associated risks is crucial—and zero trust is a proven strategy.The Zscaler ThreatLabz 2024 Phishing Report provides essential guidance to this end, including: Fighting AI with AI: Learn about Zscaler’s AI-powered phishing prevention capabilities needed to combat AI-driven threats, including preventing browser exploitation from phishing pages with Zscaler Browser Isolation Zero trust architecture advantages: Learn how the Zscaler Zero Trust Exchange prevents traditional and AI-driven phishing at multiple stages of the attack chain: Prevent compromise: TLS/SSL inspection at scale, AI-powered browser isolation and policy-driven access controls prevent access to suspicious websites. Eliminate lateral movement: Users connect directly to applications, not the network, while AI-powered app segmentation limits the blast radius of a potential incident. Shut down compromised users and insider threats: Inline inspection prevents private application exploit attempts, and integrated deception capabilities detect the most sophisticated attackers. Stop data loss: Inspection of data in-motion and at-rest prevents potential theft by an active attacker. Foundational security best practices: Learn fundamental security best practices to enhance overall resilience to phishing attacks. Download your copy of the Zscaler ThreatLabz 2024 Phishing Report today. Phishing attacks will persist and remain a pervasive threat to organizations. By understanding the latest phishing trends, assessing the associated risks, and recognizing the implications of AI-driven attacks, your organization will be better equipped to defend against phishing in 2024 and beyond.

Like many similar frameworks and languages, Struts 2 has a "developer mode" (devmode) offering additional features to aid debugging. Error messages will be more verbose, and the devmode includes an OGNL console. OGNL, the Object-Graph Navigation Language, can interact with Java, but in the end, executing OGNL results in arbitrary code execution. This OGNL console resembles a "web shell" built into devmode.  No matter the language, and the exact features it provides, enabling a "devmode", "debug mode" or similar feature in production is never a good idea. But it probably surprises no one that it still shows up in publicly exposed sites ever so often. Attackers know this as well, and are "playing" with it. To take advantage of devmode, an attacker would request a URL like: /[anything].action?debug=command&expression=[OGNL Expression] I noticed today that one URL in this format is showing up in our "first seen" URLs: /devmode.action?debug=command&expression= (#_memberAccess["allowStaticMethodAccess"]=true, #foo=new java.lang.Boolean("false") , #context["xwork.MethodAccessor.denyMethodExecution"]=#foo, @org.apache.commons.io.IOUtils For readability, I URL decoded and added spaces. This URL is likely just a scan for vulnerable systems. I ran a quick database query to see if we have other similar URLs recently. Indeed we had 2,443 distinct URLs in our database. Most of them follow this pattern: debug=command&expression=(43867*40719) Again, a simple check is performed to see if a system is vulnerable. Scans for this issue are sporadic, but we have had some notable increases recently. An old issue like this often comes back as people start to forget about it, so take this as a reminder to double-check your systems. I am plotting the last two years below, and you see big spikes on February 24th, 27th, and April 19th this year.   ---
Johannes B. Ullrich, Ph.D. , Dean of Research, SANS.edu
Twitter| (c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

By Joey Chen, Chetan Raghuprasad and Alex Karkins. 

• Cisco Talos discovered a new ongoing campaign since at least February 2024, operated by a threat actor distributing three famous infostealer malware, including Cryptbot, LummaC2 and Rhadamanthys.
• Talos also discovered a new PowerShell command-line argument embedded in the LNK file to bypass anti-virus products and download the final payload into the victims’ host.
• This campaign uses the Content Delivery Network (CDN) cache domain as a download server, hosting the malicious HTA file and payload. 
• Talos assesses with moderate confidence that the threat actor CoralRaider operates the campaign. We observed several overlaps in tactics, techniques, and procedures (TTPs) of CoralRaider’s Rotbot campaign, including the initial attack vector of the Windows Shortcut file, intermediate PowerShell decryptor and payload download scripts, the FoDHelper technique used to bypass User Access Controls (UAC) of the victim machine.  

Victimology and actor infrastructureThe campaign affects victims across multiple countries, including the U.S., Nigeria, Pakistan, Ecuador, Germany, Egypt, the U.K., Poland, the Philippines, Norway, Japan, Syria and Turkey, based on our telemetry data and OSINT information. Our telemetry also disclosed that some affected users were from Japan’s computer service call center organizations and civil defense service organizations in Syria. The affected users were downloading files masquerading as movie files through the browser, indicating the possibility of a widespread attack on users across various business verticals and geographies.We observe that this threat actor is using a Content Delivery Network (CDN) cache to store the malicious files on their network edge host in this campaign, avoiding request delay. The actor is using the CDN cache as a download server to deceive network defenders.  CDN edge URLs Information Stealerhxxps[://]techsheck[.]b-cdn[.]net/Zen90Cryptbothxxps[://]zexodown-2[.]b-cdn[.]net/Peta12Cryptbothxxps[://]denv-2[.]b-cdn[.]net/FebL5Cryptbot, Rhadamanthyshxxps[://]download-main5[.]b-cdn[.]net/BSR_v7IDccRhadamanthyshxxps[://]dashdisk-2[.]b-cdn[.]net/XFeb18Cryptbothxxps[://]metrodown-3[.]b-cdn[.]net/MebL1Cryptbothxxps[://]metrodown-2[.]b-cdn[.]net/MebL1Cryptbot, LummaC2hxxps[://]metrodown-2[.]b-cdn[.]net/SAq2LummaC2 Talos discovered that the actor is using multiple C2 domains in the campaign. The DNS requests for the domains during our analysis period are shown in the graph, indicating the campaign is ongoing. Tactics, techniques and procedures overlap with other campaigns Talos assesses with moderate confidence that threat actor CoralRaider is likely operating this campaign based on several overlaps in the TTPs used and the targeted victims’ geography of this campaign with that of the CoralRaider’s Rotbot campaign. We spotted that the PowerShell scripts used in the attack chain of this campaign to decrypt the PowerShell scripts of further stages and the downloader PowerShell script are similar to those employed in the Rotbot’s campaign. PowerShell decryptor script of Rotbot campaign (left) and new unknown campaign (right). String decrypt and download routine of Rotbot campaign (Left) and new unknown campaign (right). The Powershell script did not appear in any public repository or article, indicating the threat actor likely developed these PowerShell scripts. Pivoting on the PowerShell argument embedded in the LNK file showed us that such arguments are not popular and likely specific to the actor and the campaign.   .(gp -pa 'HKLM:\SOF*\Clas*\Applications\msh*e').('PSChildName') Multi-stage infection chain to deliver the payload The infection chain starts when a victim opens the malicious shortcut file from a ZIP file downloaded using the drive-by download technique, according to our telemetry. The threat actor is likely delivering malicious links to victims through phishing emails.The Windows shortcut file has an embedded PowerShell command running a malicious HTA file on attacker-controlled CDN domains. HTA file executes an embedded Javascript, which decodes and runs a PowerShell decrypter script. PowerShell decrypter script decrypts the embedded PowerShell Loader script and runs it in the victim’s memory. The PowerShell Loader executes multiple functions to evade the detections and bypass UAC, and finally, it downloads and runs one of the payloads, Cryptbot, LummaC2 or Rhadamanthys information stealer.Windows Shortcut file to execute the malicious HTA fileWindows shortcut file runs a PowerShell command to download and run an HTML application file on the victim’s machine. The threat actor has used “gp,” a PowerShell command alias for Get-ItemProperty, to read the registry contents of the application classes registry key and gets the executable name “mshta.exe.” Using mshta.exe, the PowerShell instance executes the remotely hosted malicious HTA file on the victim’s machine. Obfuscated HTA runs embedded PowerShell decrypter  The malicious HTML application file is heavily obfuscated and has a Javascript that decodes and executes a function using the String fromCharCode method. The decoded function then executes an embedded PowerShell decryptor script. The decryptor PowerShell script has a block of AES-encrypted string. Using the AES decryptor function, it generates an AES key of 256 bytes from a base64 encoded string “RVRVd2h4RUJHUWNiTEZpbkN5SXhzUWRHeFN4V053THQ=” and the IV “AAAAAAAAAAAAAAAA.” With the key and IV, it decrypts and executes the next stage of the PowerShell Loader script. PowerShell loader downloads and runs the payloadThe PowerShell loader script is modular and has multiple functions to perform a sequence of activities on the victim’s machine. Initially, it executes a function that drops a batch script in the victim machine’s temporary folder and writes its contents, which includes the PowerShell command to add the folder “ProgramData” of the victim machine to the Windows Defender exclusion list. The dropped bath script is executed through a living-off-the-land binary (LoLBin) “FoDHelper.exe” and a Programmatic Identifiers (ProgIDs) registry key to bypass the User Access Controls (UAC) in the victim’s machine. Fodhelper is a Windows feature, an on-demand helper binary that runs by default with high integrity. Usually, when the FodHelper is run, it checks for the presence of the registry keys listed below. If the registry keys have commands assigned, the FodHelper will execute them in an elevated context without prompting the user. HKCU:\Software\Classes\ms-settings\shell\open\commandHKCU:\Software\Classes\ms-settings\shell\open\command\DelegateExecuteHKCU:\Software\Classes\ms-settings\shell\open\command\(default)Windows Defender, by default, detects if there are attempts to write to the registry keysHKCU:\Software\Classes\ms-settings\shell\open\command and to evade this detection, the threat actor uses the programmatic identifier (ProgID). In Windows machines, a programmatic identifier (ProgID ) is a registry entry that can be associated with a Class ID (CLSID ), which is a globally unique serial number that identifies a COM (Component Object Model) class object. The Windows Shell uses a default ProgID registry key called CurVer, which is used to set the default version of a COM application. In this campaign, the threat actor abuses the “CurVer” registry key feature by creating a custom ProgID “ServiceHostXGRT” registry key in the software classes registry and assigns the Windows shell to execute a command to run the batch script.  Registry Key"HKCU\Software\Classes\ServiceHostXGRT\Shell\Open\command"Value%temp%\r.bat  The script configures the ProgID ServiceHostXGRT in the CurVer registry subkey of HKCU\Software\Classes\ms-settings\CurVer, which will get translated to HKCU:\Software\Classes\ms-settings\shell\open\command. After modifying the registry settings, the PowerShell script runs FoDHelper.exe, executing the command assigned to the registry key HKCU:\Software\Classes\ms-settings\shell\open\command and executing the dropped batch script. Finally, it deletes the configured registry keys to evade detection. The batch script adds the folder “C:\ProgramData” to the Windows Defender exclusion list. The PowerShell loader script downloads the payload and saves it in the “C:\ProgramData” folder as “X1xDd.exe.”After downloading the payload to the victim’s machine, the PowerShell loader executes another function that overwrites the previously dropped batch file with the new instructions to run the downloaded payload information stealer through the Windows start command. It again uses the same FoDHelper technique to run the batch script’s second version, which we explained earlier in this section.  Actor’s choice of three payloads in the same campaign Talos discovered that the threat actor delivered three famous information stealer malware as payloads in this campaign, including CryptBot, LummaC2 and Rhadamanthys. These information stealers target victims’ information, such as system and browser data, credentials, cryptocurrency wallets and financial information. CryptBotCryptBot is a typical infostealer targeting Windows systems discovered in the wild in 2019 by GDATA. It is designed to steal sensitive information from infected computers, such as credentials from browsers, cryptocurrency wallets, browser cookies and credit cards, and creates screenshots of the infected system. Talos has discovered a new CryptBot variant distributed in the wild since January 2024. The goal of the new CryptBot is the same, with some new innovative functionalities. The new CryptBot is packed with different techniques to obstruct malware analysis. A few new CryptBot variants are packed with VMProtect V2.0.3-2.13; others also have VMProtect, but with unknown versions. The new CryptBot attempts to steal sensitive information from infected machines and modifies the configuration changes of the stolen applications. The list of targeted browsers, applications and cryptocurrency wallets by the new variant of CryptBot is shown below.We observed the new CryptBot variant also includes password manager application databases and authenticator application information in its stealing list to steal the cryptocurrency wallets that have two-factor authentication enabled. CryptBot is aware that the target applications in the victim’s environment will have different versions, and their database files will have different file extensions. It scans the victim’s machine for database files’ extensions of the targeted applications for harvesting credentials. LummaC2 Talos discovered that the actor is delivering a new variant of LummaC2 malware as an alternative payload in this campaign. LummaC2 is a notorious information stealer that attempts to harvest information from victims’ machines. Based on the report posted by outpost24 and other external security reports, LummaC2 has already been confirmed to be sold on the underground market for years. The threat actor has modified LummaC2’s information stealer capability and obfuscated the malware with a custom algorithm. The obfuscation algorithm is saved in another section inside the malware shown below.The new version of LummaC2 also presents the same signature of the alert message displayed to the user during its execution. The C2 domains are encrypted with a symmetric algorithm, and we found that the actor has nine C2 servers that the malware will attempt to connect to one by one. Analyzing various samples of the new LummaC2 variant, we spotted that each will use a different key to encrypt the C2.   Talos has compiled the list of nine C2 domains the new LummaC2 variant attempts to connect in this campaign.  Encrypted stringsDecrypted StringsDjAX00pkpcffFUltlGiiaZwjEaPFx8U3sZYohNNzphB+VXagKwrRr7BjLA71GNEZ8E8/0K2otQ==peasanthovecapspll[.]shopDjAX00pkpcffFUltlGiiaZwjEaPFx8U3sZYohNNzphBpVXqwOAHAo75nPQT3Hc4I6EZ+x+u0rVjBgemcreedarticulateod[.]shopDjAX00pkpcffFUltlGiiaZwjEaPFx8U3sZYohNNzphB9VXShLxDMqLFmPATgC8Ma+U14zKy0oBnC/kf0secretionsuitcasenioise[.]shopDjAX00pkpcffFUltlGiiaZwjEaPFx8U3sZYohNNzphBtXHa6JwfKqbxwOh79B8wb+UF0jbavqkc=claimconcessionrebe[.]shopDjAX00pkpcffFUltlGiiaZwjEaPFx8U3sZYohNNzphBiWXaxIwjMs6Z0Ox/1BsUM8UZ/2qyz60TZ+Vg=liabilityarrangemenyit[.]shopDjAX00pkpcffFUltlGiiaZwjEaPFx8U3sZYohNNzphBjX3O2ORDAtKx0MAjiDcwE9U9mxq7ptl/e5g==modestessayevenmilwek[.]shopDjAX00pkpcffFUltlGiiaZwjEaPFx8U3sZYohNNzphB6Qn6yJAPJoqxwKB77BsAM8kB51K/ptl/e5g==triangleseasonbenchwj[.]shopDjAX00pkpcffFUltlGiiaZwjEaPFx8U3sZYohNNzphBtRXunPxbAtLRwPQ78DssH/U1yyqSrqRnC/kf0culturesketchfinanciall[.]shopDjAX00pkpcffFUltlGiiaZwjEaPFx8U3sZYohNNzphB9X3GyIhHLs7Z7Lh74AcYM+Ep/xuu0rVjBsofahuntingslidedine[.]shop LummaC2’s first step in its exfiltration phase is its connection to the C2 server. The malware will exit the process if it does not receive the “OK” message as a response from any of the nine C2 servers. The second step will be exfiltrating information from infected machines. The basic stealing functionality is the same as the previous version, with the addition of victims’ discord credentials to exfiltrate. RhadamanthysThe last payload we found in this campaign is Rhadamanthys malware, a famous infostealer appearing in the underground forum advertisement in September 2022. The Rhadamanthys malware has been evolving till now, and its authors have released a new version, V0.6.0, on Feb. 15, 2024. However, the Rhadamanthys variant we found in this campaign is still v0.5.0.The threat actor uses a Python executable file as a loader to execute the Rhadamanthys malware into memory. After decompiling the Python executable file, Python scripts load the Rhadamanthys malware in two stages. The first stage is a simple Python script that replaces the binary code from 0 to 9 and decodes the second stage. In the second stage, the Python script uses the Windows API to allocate a memory block and inject Rhadamanthys malware into the process. We spotted that the threat actor is developing the Python script with the intention of including the functionality of executing a shellcode. Analyzing the final executable file showed us that the malware unpacks the loader module with the custom format having the magic header “XS” and performs the process injection. The custom loader module in XS format is similar to that of a Rhadamanthys sample analyzed by the researcher at Check Point. The malware selects one of the listed processes as the target process for process injection from a hardcoded list in the binary:

• "%Systemroot%\\system32\\dialer.exe"
• "%Systemroot%\\system32\\openwith.exe"

CoverageCisco Secure Endpoint (formerly AMP for Endpoints) is ideally suited to prevent the execution of the malware detailed in this post. Try Secure Endpoint for free here.Cisco Secure Web Appliance web scanning prevents access to malicious websites and detects malware used in these attacks.Cisco Secure Email (formerly Cisco Email Security) can block malicious emails sent by threat actors as part of their campaign. You can try Secure Email for free here.Cisco Secure Firewall (formerly Next-Generation Firewall and Firepower NGFW) appliances such as Threat Defense Virtual, Adaptive Security Appliance and Meraki MX can detect malicious activity associated with this threat.Cisco Secure Malware Analytics (Threat Grid) identifies malicious binaries and builds protection into all Cisco Secure products.Umbrella, Cisco's secure internet gateway (SIG), blocks users from connecting to malicious domains, IPs and URLs, whether users are on or off the corporate network. Sign up for a free trial of Umbrella here.Cisco Secure Web Appliance (formerly Web Security Appliance) automatically blocks potentially dangerous sites and tests suspicious sites before users access them.Additional protections with context to your specific environment and threat data are available from the Firewall Management Center.Cisco Duo provides multi-factor authentication for users to ensure only those authorized are accessing your network.Open-source Snort Subscriber Rule Set customers can stay up to date by downloading the latest rule pack available for purchase on Snort.org. Snort SID for this threat is 63218 - 63225 and 300867 - 300870.ClamAV detections are also available for this threat:Lnk.Downloader.CoralRaider-10027128-0Txt.Tool.CoralRaider-10027140-0Html.Downloader.CoralRaider-10027220-0Win.Infostealer.Lumma-10027222-0Win.Infostealer.Rhadamanthys-10027293-0Win.Infostealer.Rhadamanthys-10027294-0Win.Infostealer.Cryptbot-10027295-0Win.Infostealer.Cryptbot-10027296-0Win.Infostealer.Cryptbot-10027297-0Win.Infostealer.Cryptbot-10027298-0Win.Infostealer.Cryptbot-10027299-0Win.Infostealer.Cryptbot-10027300-0Win.Infostealer.Cryptbot-10027301-0Win.Infostealer.Cryptbot-10027302-0Win.Infostealer.Cryptbot-10027303-0Win.Infostealer.Cryptbot-10027305-0 Indicators of CompromiseIndicators of Compromise associated with this threat can be found here.

The content of this post is solely the responsibility of the author.  AT&T does not adopt or endorse any of the views, positions, or information provided by the author in this article.  In an era where technology and transportation converge, the fusion of vehicles with IoT technologies heralds a new dawn of mobility. This leap forward promises enhanced connectivity and autonomous capabilities, yet casts a shadow of cyber vulnerabilities that could jeopardize not just the integrity of the vehicles but the safety of their passengers. Recognizing the urgency of this issue, the UNECE stepped forward with the R155 regulation, a vanguard initiative to fortify the digital fortresses of our vehicles against potential cyber onslaughts. The Genesis of UNECE R155: Forging the Shields of Cybersecurity The essence of the UNECE R155 regulation unfolds as a carefully crafted framework designed to preemptively address the burgeoning threat landscape in the automotive sector. Rooted in the principle of proactive defense, R155 isn't just about compliance; it represents a paradigm shift in how vehicle cybersecurity is perceived and integrated. At its core, the regulation mandates the establishment of a Cybersecurity Management System (CSMS), compelling manufacturers to weave a tapestry of cyber resilience that spans the entire lifecycle of a vehicle. The ambition of R155 is pretty clear at this point: to transform the automotive industry's approach to cybersecurity from reactive patchwork to a strategic, foundational pillar. This involves not only the adoption of 'security by design' principles but also a commitment to continual vigilance and adaptation in the face of evolving cyber threats. The regulation, thus, sets the stage for a future where vehicles are not merely transport mechanisms but fortified nodes within an expansive network of connected mobility. The Journey to CSMS Certification The path to CSMS certification under R155 is a clear yet challenging journey that demands attention to detail and a commitment to security from vehicle manufacturers. This process starts with a considerable risk assessment, where manufacturers must identify any potential cybersecurity risks within their vehicles. This step is crucial for understanding where vulnerabilities might exist and how they can be addressed to ensure vehicles are secure. Following this, the principle of 'security by design' becomes central to the certification process. This means that from the very beginning of designing a vehicle, cybersecurity needs to be a key consideration. It's about making sure that security measures are built into the vehicle from the start, rather than being added on later. This approach challenges manufacturers to think about cybersecurity as an integral part of the vehicle, just like its engine or wheels. Achieving certification is a team effort that involves not only the manufacturers but also suppliers and regulatory bodies. It's about working together to make sure that every part of the vehicle, from its software to its hardware, meets the high security standards set out by R155. Addressing R155 Implementation Challenges As manufacturers and suppliers are gearing up to align with the R155 regulation, however, they encounter a set of practical challenges that test their adaptability and foresight. One of the most significant hurdles is the pressing need for new skills. The detailed cybersecurity requirements of R155 demand a workforce that is not only proficient in traditional automotive engineering but also versed in the nuances of cybersecurity. This dual expertise is not commonplace, prompting organizations to invest in extensive training or scout for new talent, adding layers of complexity to their operational dynamics. Another considerable challenge lies in the adjustments required in the design processes. The 'security by design' principle advocated by R155 necessitates a paradigm shift in how vehicles are conceived. Manufacturers are tasked with integrating cybersecurity measures right from the conceptual stages, ensuring these considerations are as fundamental as the vehicle's performance or aesthetics. This shift often means reevaluating established workflows and possibly extending development timelines to accommodate the additional focus on cybersecurity. The early integration of cybersecurity considerations presents its own set of complexities. It demands a proactive approach where potential risks are identified and mitigated well before they can manifest into vulnerabilities. This proactive stance requires a deep understanding of cyber threats and an ability to anticipate future challenges, pushing manufacturers to remain vigilant and responsive to the rapidly evolving cyber landscape. Together, these challenges underscore the demanding nature of R155 compliance. They reflect the regulation's comprehensive approach to enhancing automotive cybersecurity but also highlight the significant effort required from manufacturers and suppliers to meet these standards. R155's Transformative Impact on the Automotive Industry The introduction of the UNECE R155 regulation marks a pivotal moment for the automotive industry, heralding a new era of digital resilience and consumer trust. One of the most significant outcomes of this regulation is the bolstering of cybersecurity across the board, creating vehicles that are not just smarter but safer. This heightened security is a boon for consumer confidence, as buyers increasingly prioritize digital safety in their connected vehicles alongside traditional safety measures. However, the journey to compliance is not without its challenges. The implementation of R155 entails considerable investment from manufacturers and suppliers, not just financially but also in terms of time and resources. Developing and integrating advanced cybersecurity measures, training staff, and adapting to new design processes contribute to rising operational costs. Moreover, the dynamic nature of cyber threats necessitates an ongoing commitment to vigilance and adaptation, adding a layer of continuous effort in monitoring and updating cybersecurity measures. Despite these challenges, the regulation's comprehensive approach to cybersecurity is a testament to the industry's commitment to safeguarding the digital integrity of vehicles. It represents a significant step forward in protecting not only the vehicles and the networks they connect to but, most importantly, the people they serve. Steering Into a Secure Future As we reflect on the journey through the intricacies of the UNECE R155 regulation, it's clear that its impact extends far beyond the immediate challenges of implementation. R155 is not just a set of requirements; it's a catalyst for change, driving the automotive industry toward a future where digital safety is ingrained in every vehicle that rolls off the production line. The road ahead is undoubtedly challenging, with hurdles like the need for new skills, rising costs, and the demand for ongoing vigilance. Yet, the destination—a world where vehicles are as secure in the digital realm as they are on the road—is worth every effort. Embracing R155 is about more than compliance; it's about committing to a vision of automotive innovation that places security at its heart. As manufacturers, suppliers, and regulatory bodies come together to navigate these changes, they pave the way for an industry that prioritizes the safety and trust of its consumers above all. In this digital age, where connectivity and cybersecurity are intertwined, the automotive industry's journey toward enhanced digital resilience under R155 is a beacon of progress, illuminating the path toward a safer, more secure automotive future.

By Max Ammann This blog showcases five examples of real-world vulnerabilities that we’ve disclosed in the past year (but have not publicly disclosed before). We also share the frustrations we faced in disclosing them to illustrate the need for effective disclosure processes. Here are the five bugs:

• Undefined behavior in the borsh-rs Rust library
• Denial-of-service (DoS) vector in Rust libraries for parsing the Ethereum ABI
• Missing limit on authentication tag length in Expo
• DoS vector in the num-bigint Rust library
• Insertion of MMKV database encryption key into Android system log with react-native-mmkv

Discovering a vulnerability in an open-source project necessitates a careful approach, as publicly reporting it (also known as full disclosure) can alert attackers before a fix is ready. Coordinated vulnerability disclosure (CVD) uses a safer, structured reporting framework to minimize risks. Our five example cases demonstrate how the lack of a CVD process unnecessarily complicated reporting these bugs and ensuring their remediation in a timely manner. In the Takeaways section, we show you how to set up your project for success by providing a basic security policy you can use and walking you through a streamlined disclosure process called GitHub private reporting. GitHub’s feature has several benefits:

• Discreet and secure alerts to developers: no need for PGP-encrypted emails
• Streamlined process: no playing hide-and-seek with company email addresses
• Simple CVE issuance: no need to file a CVE form at MITRE

Time for action: If you own well-known projects on GitHub, use private reporting today! Read more on Configuring private vulnerability reporting for a repository, or skip to the Takeaways section of this post. Case 1: Undefined behavior in borsh-rs Rust library The first case, and reason for implementing a thorough security policy, concerned a bug in a cryptographic serialization library called borsh-rs that was not fixed for two years. During an audit, I discovered unsafe Rust code that could cause undefined behavior if used with zero-sized types that don’t implement the Copy trait. Even though somebody else reported this bug previously, it was left unfixed because it was unclear to the developers how to avoid the undefined behavior in the code and keep the same properties (e.g., resistance against a DoS attack). During that time, the library’s users were not informed about the bug. The whole process could have been streamlined using GitHub’s private reporting feature. If project developers cannot address a vulnerability when it is reported privately, they can still notify Dependabot users about it with a single click. Releasing an actual fix is optional when reporting vulnerabilities privately on GitHub. I reached out to the borsh-rs developers about notifying users while there was no fix available. The developers decided that it was best to notify users because only certain uses of the library caused undefined behavior. We filed the notification RUSTSEC-2023-0033, which created a GitHub advisory. A few months later, the developers fixed the bug, and the major release 1.0.0 was published. I then updated the RustSec advisory to reflect that it was fixed. The following code contained the bug that caused undefined behavior: impl<T> BorshDeserialize for Vec<T> where T: BorshDeserialize, { #[inline] fn deserialize<R: Read>(reader: &mut R) -> Result<Self, Error> { let len = u32::deserialize(reader)?; if size_of::<T>() == 0 { let mut result = Vec::new(); result.push(T::deserialize(reader)?); let p = result.as_mut_ptr(); unsafe { forget(result); let len = len as usize; let result = Vec::from_raw_parts(p, len, len); Ok(result) } } else { // TODO(16): return capacity allocation when we can safely do that. let mut result = Vec::with_capacity(hint::cautious::<T>(len)); for _ in 0..len { result.push(T::deserialize(reader)?); } Ok(result) } } } Figure 1: Use of unsafe Rust (borsh-rs/borsh-rs/borsh/src/de/mod.rs#123–150) The code in figure 1 deserializes bytes to a vector of some generic data type T. If the type T is a zero-sized type, then unsafe Rust code is executed. The code first reads the requested length for the vector as u32. After that, the code allocates an empty Vec type. Then it pushes a single instance of T into it. Later, it temporarily leaks the memory of the just-allocated Vec by calling the forget function and reconstructs it by setting the length and capacity of Vec to the requested length. As a result, the unsafe Rust code assumes that T is copyable. The unsafe Rust code protects against a DoS attack where the deserialized in-memory representation is significantly larger than the serialized on-disk representation. The attack works by setting the vector length to a large number and using zero-sized types. An instance of this bug is described in our blog post Billion times emptiness. Case 2: DoS vector in Rust libraries for parsing the Ethereum ABI In July, I disclosed multiple DoS vulnerabilities in four Ethereum API–parsing libraries, which were difficult to report because I had to reach out to multiple parties. The bug affected four GitHub-hosted projects. Only the Python project eth_abi had GitHub private reporting enabled. For the other three projects (ethabi, alloy-rs, and ethereumjs-abi), I had to research who was maintaining them, which can be error-prone. For instance, I had to resort to the trick of getting email addresses from maintainers by appending the suffix .patch to GitHub commit URLs. The following link shows the non-work email address I used for committing: https://github.com/trailofbits/publications/commit/a2ab5a1cab59b52c4fa
71b40dae1f597bc063bdf.patch In summary, as the group of affected vendors grows, the burden on the reporter grows as well. Because you typically need to synchronize between vendors, the effort does not grow linearly but exponentially. Having more projects use the GitHub private reporting feature, a security policy with contact information, or simply an email in the README file would streamline communication and reduce effort. Read more about the technical details of this bug in the blog post Billion times emptiness. Case 3: Missing limit on authentication tag length in Expo In late 2022, Joop van de Pol, a security engineer at Trail of Bits, discovered a cryptographic vulnerability in expo-secure-store. In this case, the vendor, Expo, failed to follow up with us about whether they acknowledged or had fixed the bug, which left us in the dark. Even worse, trying to follow up with the vendor consumed a lot of time that could have been spent finding more bugs in open-source software. When we initially emailed Expo about the vulnerability through the email address listed on its GitHub, secure@expo.io, an Expo employee responded within one day and confirmed that they would forward the report to their technical team. However, after that response, we never heard back from Expo despite two gentle reminders over the course of a year. Unfortunately, Expo did not allow private reporting through GitHub, so the email was the only contact address we had. Now to the specifics of the bug: on Android above API level 23, SecureStore uses AES-GCM keys from the KeyStore to encrypt stored values. During encryption, the tag length and initialization vector (IV) are generated by the underlying Java crypto library as part of the Cipher class and are stored with the ciphertext: /* package */ JSONObject createEncryptedItem(Promise promise, String plaintextValue, Cipher cipher, GCMParameterSpec gcmSpec, PostEncryptionCallback postEncryptionCallback) throws GeneralSecurityException, JSONException { byte[] plaintextBytes = plaintextValue.getBytes(StandardCharsets.UTF_8); byte[] ciphertextBytes = cipher.doFinal(plaintextBytes); String ciphertext = Base64.encodeToString(ciphertextBytes, Base64.NO_WRAP); String ivString = Base64.encodeToString(gcmSpec.getIV(), Base64.NO_WRAP); int authenticationTagLength = gcmSpec.getTLen(); JSONObject result = new JSONObject() .put(CIPHERTEXT_PROPERTY, ciphertext) .put(IV_PROPERTY, ivString) .put(GCM_AUTHENTICATION_TAG_LENGTH_PROPERTY, authenticationTagLength); postEncryptionCallback.run(promise, result); return result; } Figure 2: Code for encrypting an item in the store, where the tag length is stored next to the cipher text (SecureStoreModule.java) For decryption, the ciphertext, tag length, and IV are read and then decrypted using the AES-GCM key from the KeyStore. An attacker with access to the storage can change an existing AES-GCM ciphertext to have a shorter authentication tag. Depending on the underlying Java cryptographic service provider implementation, the minimum tag length is 32 bits in the best case (this is the minimum allowed by the NIST specification), but it could be even lower (e.g., 8 bits or even 1 bit) in the worst case. So in the best case, the attacker has a small but non-negligible probability that the same tag will be accepted for a modified ciphertext, but in the worst case, this probability can be substantial. In either case, the success probability grows depending on the number of ciphertext blocks. Also, both repeated decryption failures and successes will eventually disclose the authentication key. For details on how this attack may be performed, see Authentication weaknesses in GCM from NIST. From a cryptographic point of view, this is an issue. However, due to the required storage access, it may be difficult to exploit this issue in practice. Based on our findings, we recommended fixing the tag length to 128 bits instead of writing it to storage and reading it from there. The story would have ended here since we didn’t receive any responses from Expo after the initial exchange. But in our second email reminder, we mentioned that we were going to publicly disclose this issue. One week later, the bug was silently fixed by limiting the minimum tag length to 96 bits. Practically, 96 bits offers sufficient security. However, there is also no reason not to go with the higher 128 bits. The fix was created exactly one week after our last reminder. We suspect that our previous email reminder led to the fix, but we don’t know for sure. Unfortunately, we were never credited appropriately. Case 4: DoS vector in the num-bigint Rust library In July 2023, Sam Moelius, a security engineer at Trail of Bits, encountered a DoS vector in the well-known num-bigint Rust library. Even though the disclosure through email worked very well, users were never informed about this bug through, for example, a GitHub advisory or CVE. The num-bigint project is hosted on GitHub, but GitHub private reporting is not set up, so there was no quick way for the library author or us to create an advisory. Sam reported this bug to the developer of num-bigint by sending an email. But finding the developer’s email is error-prone and takes time. Instead of sending the bug report directly, you must first confirm that you’ve reached the correct person via email and only then send out the bug details. With GitHub private reporting or a security policy in the repository, the channel to send vulnerabilities through would be clear. But now let’s discuss the vulnerability itself. The library implements very large integers that no longer fit into primitive data types like i128. On top of that, the library can also serialize and deserialize those data types. The vulnerability Sam discovered was hidden in that serialization feature. Specifically, the library can crash due to large memory consumption or if the requested memory allocation is too large and fails. The num-bigint types implement traits from Serde. This means that any type in the crate can be serialized and deserialized using an arbitrary file format like JSON or the binary format used by the bincode crate. The following example program shows how to use this deserialization feature: use num_bigint::BigUint; use std::io::Read; fn main() -> std::io::Result<()> { let mut buf = Vec::new(); let _ = std::io::stdin().read_to_end(&mut buf)?; let _: BigUint = bincode::deserialize(&buf).unwrap_or_default(); Ok(()) } Figure 3: Example deserialization format It turns out that certain inputs cause the above program to crash. This is because implementing the Visitor trait uses untrusted user input to allocate a specific vector capacity. The following figure shows the lines that can cause the program to crash with the message memory allocation of 2893606913523067072 bytes failed. impl<'de> Visitor<'de> for U32Visitor { type Value = BigUint; {...omitted for brevity...} #[cfg(not(u64_digit))] fn visit_seq<S>(self, mut seq: S) -> Result<Self::Value, S::Error> where S: SeqAccess<'de>, { let len = seq.size_hint().unwrap_or(0); let mut data = Vec::with_capacity(len); {...omitted for brevity...} } #[cfg(u64_digit)] fn visit_seq<S>(self, mut seq: S) -> Result<Self::Value, S::Error> where S: SeqAccess<'de>, { use crate::big_digit::BigDigit; use num_integer::Integer; let u32_len = seq.size_hint().unwrap_or(0); let len = Integer::div_ceil(&u32_len, &2); let mut data = Vec::with_capacity(len); {...omitted for brevity...} } } Figure 4: Code that allocates memory based on user input (num-bigint/src/biguint/serde.rs#61–108) We initially contacted the author on July 20, 2023, and the bug was fixed in commit 44c87c1 on August 22, 2023. The fixed version was released the next day as 0.4.4. Case 5: Insertion of MMKV database encryption key into Android system log with react-native-mmkv The last case concerns the disclosure of a plaintext encryption key in the react-native-mmkv library, which was fixed in September 2023. During a secure code review for a client, I discovered a commit that fixed an untracked vulnerability in a critical dependency. Because there was no security advisory or CVE ID, neither I nor the client were informed about the vulnerability. The lack of vulnerability management caused a situation where attackers knew about a vulnerability, but users were left in the dark. During the client engagement, I wanted to validate how the encryption key was used and handled. The commit fix: Don’t leak encryption key in logs in the react-native-mmkv library caught my attention. The following code shows the problematic log statement: MmkvHostObject::MmkvHostObject(const std::string& instanceId, std::string path, std::string cryptKey) { __android_log_print(ANDROID_LOG_INFO, "RNMMKV", "Creating MMKV instance \"%s\"... (Path: %s, Encryption-Key: %s)", instanceId.c_str(), path.c_str(), cryptKey.c_str()); std::string* pathPtr = path.size() > 0 ? &path : nullptr; {...omitted for brevity...} Figure 5: Code that initializes MMKV and also logs the encryption key Before that fix, the encryption key I was investigating was printed in plaintext to the Android system log. This breaks the threat model because this encryption key should not be extractable from the device, even with Android debugging features enabled. With the client’s agreement, I notified the author of react-native-mmkv, and the author and I concluded that the library users should be informed about the vulnerability. So the author enabled private reporting and together we published a GitHub advisory. The ID CVE-2024-21668 was assigned to the bug. The advisory now alerts developers if they use a vulnerable version of react-native-mmkv when running npm audit or npm install. This case highlights that there is basically no way around GitHub advisories when it comes to npm packages. The only way to feed the output of the npm audit command is to create a GitHub advisory. Using private reporting streamlines that process. Takeaways GitHub’s private reporting feature contributes to securing the software ecosystem. If used correctly, the feature saves time for vulnerability reporters and software maintainers. The biggest impact of private reporting is that it is linked to the GitHub advisory database—a link that is missing, for example, when using confidential issues in GitLab. With GitHub’s private reporting feature, there is now a process for security researchers to publish to that database (with the approval of the repository maintainers). The disclosure process also becomes clearer with a private report on GitHub. When using email, it is unclear whether you should encrypt the email and who you should send it to. If you’ve ever encrypted an email, you know that there are endless pitfalls. However, you may still want to send an email notification to developers or a security contact, as maintainers might miss GitHub notifications. A basic email with a link to the created advisory is usually enough to raise awareness. Step 1: Add a security policy Publishing a security policy is the first step towards owning a vulnerability reporting process. To avoid confusion, a good policy clearly defines what to do if you find a vulnerability. GitHub has two ways to publish a security policy. Either you can create a SECURITY.md file in the repository root, or you can create a user- or organization-wide policy by creating a .github repository and putting a SECURITY.md file in its root. We recommend starting with a policy generated using the Policymaker by disclose.io (see this example), but replace the Official Channels section with the following: We have multiple channels for receiving reports: * If you discover any security-related issues with a specific GitHub project, click the *Report a vulnerability* button on the *Security* tab in the relevant GitHub project: https://github.com/%5BYOUR_ORG%5D/%5BYOUR_PROJECT%5D.
* Send an email to security@example.com Always make sure to include at least two points of contact. If one fails, the reporter still has another option before falling back to messaging developers directly. Step 2: Enable private reporting Now that the security policy is set up, check out the referenced GitHub private reporting feature, a tool that allows discreet communication of vulnerabilities to maintainers so they can fix the issue before it’s publicly disclosed. It also notifies the broader community, such as npm, Crates.io, or Go users, about potential security issues in their dependencies. Enabling and using the feature is easy and requires almost no maintenance. The only key is to make sure that you set up GitHub notifications correctly. Reports get sent via email only if you configure email notifications. The reason it’s not enabled by default is that this feature requires active monitoring of your GitHub notifications, or else reports may not get the attention they require. After configuring the notifications, go to the “Security” tab of your repository and click “Enable vulnerability reporting”: Emails about reported vulnerabilities have the subject line “(org/repo) Summary (GHSA-0000-0000-0000).” If you use the website notifications, you will get one like this: If you want to enable private reporting for your whole organization, then check out this documentation. A benefit of using private reporting is that vulnerabilities are published in the GitHub advisory database (see the GitHub documentation for more information). If dependent repositories have Dependabot enabled, then dependencies to your project are updated automatically. On top of that, GitHub can also automatically issue a CVE ID that can be used to reference the bug outside of GitHub. This private reporting feature is still officially in beta on GitHub. We encountered minor issues like the lack of message templates and the inability of reporters to add collaborators. We reported the latter as a bug to GitHub, but they claimed that this was by design. Step 3: Get notifications via webhooks If you want notifications in a messaging platform of your choice, such as Slack, you can create a repository- or organization-wide webhook on GitHub. Just enable the following event type: After creating the webhook, repository_advisory events will be sent to the set webhook URL. The event includes the summary and description of the reported vulnerability. How to make security researchers happy If you want to increase your chances of getting high-quality vulnerability reports from security researchers and are already using GitHub, then set up a security policy and enable private reporting. Simplifying the process of reporting security bugs is important for the security of your software. It also helps avoid researchers becoming annoyed and deciding not to report a bug or, even worse, deciding to turn the vulnerability into an exploit or release it as a 0-day. If you use GitHub, this is your call to action to prioritize security, protect the public software ecosystem’s security, and foster a safer development environment for everyone by setting up a basic security policy and enabling private reporting. If you’re not a GitHub user, similar features also exist on other issue-tracking systems, such as confidential issues in GitLab. However, not all systems have this option; for instance, Gitea is missing such a feature. The reason we focused on GitHub in this post is because the platform is in a unique position due to its advisory database, which feeds into, for example, the npm package repository. But regardless of which platform you use, make sure that you have a visible security policy and reliable channels set up.

From 2018 to 2023, healthcare data breaches have increased by 93 percent. And ransomware attacks have grown by 278 percent over the same period. Healthcare organizations can’t afford to let preventable breaches slip by. Globally, the average cost of a healthcare data breach has reached $10.93 million. The situation for healthcare organizations may seem bleak. But there is hope. Focus on layering your security posture to focus on threat prevention, protection, and recovery. Check out three healthcare organizations that are strengthening their cyber resilience with layered security tools. 1. Memorial Hermann balances user experience with encryption Email encryption keeps sensitive medical data safe and organizations compliant. Unfortunately, providers will skip it if the encryption tool is difficult to use. Memorial Hermann ran into this exact issue. Juggling compliance requirements with productivity needs, the organization worried about the user experience for email encryption. Webroot Email Encryption powered by Zix provides the solution. Nearly 75 percent of Memorial Hermann’s encrypted emails go to customers who share Webroot. Now more than 1,750 outside organizations can access encrypted email right from their inbox, with no extra steps or passwords. Read the full case study. 2. Allergy, Asthma and Sinus Center safeguards email The center needed to protect electronic medical records (EMR). But its old software solution required technical oversight that was difficult to manage. Webroot Email Threat Protection by OpenText gives the healthcare organization an easy way to keep EMR secure. OpenText’s in-house research team is continually monitoring new and emerging threats to ensure the center’s threat protection is always up to date. With high-quality protection and a low-maintenance design, the IT team can focus on other projects. When patient data is at stake, the center knows it can trust Webroot. Read the full case study. 3. Radiology Associates avoid downtime with fast recovery Radiologists need to read and interpret patient reports so they can quickly share them with doctors. Their patients’ health can’t afford for them to have downtime. After an unexpected server crash corrupted its database, Radiology Associates needed a way to avoid workflow interruptions. Carbonite Recover by OpenText helps the organization get back to business quickly in the event of a data breach or natural disaster. Plus, the price of the solution and ease of use gave Radiology Associates good reasons to choose our solution. Read the full case study. Conclusion As ransomware becomes more sophisticated and data breaches occur more frequently, healthcare organizations must stay vigilant. Strong cyber resilience should be a priority so that you can protect patient privacy and maintain trust within the healthcare industry. And you don’t have to do it alone. We’re ready to help out as your trusted cybersecurity partner. Together, we can prevent data breaches, protect sensitive data, and help you recover when disaster strikes. Contact us to learn more about our cybersecurity solutions. The post 3 healthcare organizations that are building cyber resilience appeared first on Webroot Blog.

Ransomware attacks are targeting healthcare organizations more frequently. The number of costly cyberattacks on US hospitals has doubled. So how do you prevent these attacks? Keep reading to learn five ways you can strengthen security at your organization. But first, let’s find out what’s at stake. Why healthcare needs better cybersecurity Healthcare organizations are especially vulnerable to data breaches because of how much data they hold. And when a breach happens, it creates financial burdens and affects regulatory compliance. On average, the cost of a healthcare data breach globally is $10.93 million. Noncompliance not only incurs more costs but also hurts patient trust. Once that trust is lost, it’s difficult to regain it, which can impact your business and standing within the industry. Adopting a layered security approach will help your organization prevent these attacks. Here are five ways to strengthen your cybersecurity: 1. Use preventive security technology Prevention, as the saying goes, prevention is better than the cure. With the right systems and the right methodology, it’s possible to detect and intercept most cyberthreats before they lead to a data breach, a loss of service, or a deterioration in patient care.
Examples of prevention-layer technologies include:

• Endpoint protection keeps out malicious files, scripts, URLs, and exploits via a cloud-based architecture.
• Email encryption makes it hard for attackers to intercept sensitive medical data—just make sure the encryption tool is easy to manage and use.
• Email threat protection and continuity safeguards electronic medical records by monitoring emerging threats.

2. Provide cybersecurity training According to Verizon, 82 percent of all breaches involve a human element. Sometimes malicious insiders create security vulnerabilities. Other times, well-intentioned employees fall victim to attacks like phishing, legitimate-looking emails that trick employees into giving attackers their credentials or other sensitive information—like patient data. In fact, 16 percent of breaches start with phishing. When your employees receive basic cybersecurity training, they are more likely to recognize bad actors, report suspicious activity, and avoid risky behavior. You can outsource cybersecurity training or find an automated security training solution that you manage. 3. Ensure regulatory compliance Healthcare providers are subject to strict data privacy regulations like HIPPA and GDPR. If an avoidable data breach occurs, organizations face hefty fines from state and federal authorities. The email and endpoint protection tools described above help you stay compliant with these regulations. But sometimes a breach is out of your control. So regulators have provided guidelines for how to respond, including investigation, notification, and recovery. 4. Build business recovery plans Adding a recovery plan to your multilayered security approach is crucial to achieving and maintaining cyber resilient healthcare. Ideally, you’ll catch most incoming threats before they become an issue. However, the recovery layer is critical when threats do get through or disasters occur. You might think that your cloud-based applications back up and secure your data. But SaaS vendors explicitly state that data protection and backup is the customer’s responsibility of the customer. Some SaaS applications have recovery options, but they’re limited and ineffective. A separate backup system is necessary to ensure business continuity. Reasons for implementing a solid recovery strategy include:

• Re-establishing patient trust.
• Avoiding disruptions to patient care.
• Remaining compliant with HIPPA and GDPR requirements.

Remember, lives depend on getting your systems back up quickly. That’s why your healthcare organization needs a secure, continuously updated backup and recovery solution for local and cloud servers. 5. Monitor and improve continuously Once you have your multilayered security approach in place, you’ll need a centralized management console to help you monitor and control all your security services. This single-pane-of-glass gives you real-time cyber intelligence and all the tools you need to protect your healthcare organization, your reputation, and your investment in digital transformation. You can also spot gaps in your approach and find ways to improve. Conclusion Cybersecurity can seem daunting at times. Just remember that every step you take toward cyber resilience helps you protect patient privacy and maintain your credibility within the healthcare industry.
So when you’re feeling overwhelmed or stuck, remember the five ways you can strengthen your layered cybersecurity approach:

1. Use preventive technology like endpoint protection and email encryption.
2. Train your employees to recognize malicious activities like phishing.
3. Ensure that you’re compliant with HIPPA, GDPR, and any other regulation standards.
4. Retrieve your data from breaches with backup and recovery tools.
5. Monitor your data and improve your approach when necessary.

The post 5 ways to strengthen healthcare cybersecurity appeared first on Webroot Blog.

Authored by Joshua Kamp Executive summary The authors behind Android banking malware Vultur have been spotted adding new technical features, which allow the malware operator to further remotely interact with the victim’s mobile device. Vultur has also started masquerading more of its malicious activity by encrypting its C2 communication, using multiple encrypted payloads that are decrypted on the fly, and using the guise of legitimate applications to carry out its malicious actions. Key takeaways

• The authors behind Vultur, an Android banker that was first discovered in March 2021, have been spotted adding new technical features.
• New technical features include the ability to:
  • Download, upload, delete, install, and find files;
  • Control the infected device using Android Accessibility Services (sending commands to perform scrolls, swipe gestures, clicks, mute/unmute audio, and more);
  • Prevent apps from running;
  • Display a custom notification in the status bar;
  • Disable Keyguard in order to bypass lock screen security measures.
• While the new features are mostly related to remotely interact with the victim’s device in a more flexible way, Vultur still contains the remote access functionality using AlphaVNC and ngrok that it had back in 2021.
• Vultur has improved upon its anti-analysis and detection evasion techniques by:
  • Modifying legitimate apps (use of McAfee Security and Android Accessibility Suite package name);
  • Using native code in order to decrypt payloads;
  • Spreading malicious code over multiple payloads;
  • Using AES encryption and Base64 encoding for its C2 communication.

Introduction Vultur is one of the first Android banking malware families to include screen recording capabilities. It contains features such as keylogging and interacting with the victim’s device screen. Vultur mainly targets banking apps for keylogging and remote control. Vultur was first discovered by ThreatFabric in late March 2021. Back then, Vultur (ab)used the legitimate software products AlphaVNC and ngrok for remote access to the VNC server running on the victim’s device. Vultur was distributed through a dropper-framework called Brunhilda, responsible for hosting malicious applications on the Google Play Store [1]. The initial blog on Vultur uncovered that there is a notable connection between these two malware families, as they are both developed by the same threat actors [2]. In a recent campaign, the Brunhilda dropper is spread in a hybrid attack using both SMS and a phone call. The first SMS message guides the victim to a phone call. When the victim calls the number, the fraudster provides the victim with a second SMS that includes the link to the dropper: a modified version of the McAfee Security app. The dropper deploys an updated version of Vultur banking malware through 3 payloads, where the final 2 Vultur payloads effectively work together by invoking each other’s functionality. The payloads are installed when the infected device has successfully registered with the Brunhilda Command-and-Control (C2) server. In the latest version of Vultur, the threat actors have added a total of 7 new C2 methods and 41 new Firebase Cloud Messaging (FCM) commands. Most of the added commands are related to remote access functionality using Android’s Accessibility Services, allowing the malware operator to remotely interact with the victim’s screen in a way that is more flexible compared to the use of AlphaVNC and ngrok. In this blog we provide a comprehensive analysis of Vultur, beginning with an overview of its infection chain. We then delve into its new features, uncover its obfuscation techniques and evasion methods, and examine its execution flow. Following that, we dissect its C2 communication, discuss detection based on YARA, and draw conclusions. Let’s soar alongside Vultur’s smarter mobile malware strategies! Infection chain In order to deceive unsuspecting individuals into installing malware, the threat actors employ a hybrid attack using two SMS messages and a phone call. First, the victim receives an SMS message that instructs them to call a number if they did not authorise a transaction involving a large amount of money. In reality, this transaction never occurred, but it creates a false sense of urgency to trick the victim into acting quickly. A second SMS is sent during the phone call, where the victim is instructed into installing a trojanised version of the McAfee Security app from a link. This application is actually Brunhilda dropper, which looks benign to the victim as it contains functionality that the original McAfee Security app would have. As illustrated below, this dropper decrypts and executes a total of 3 Vultur-related payloads, giving the threat actors total control over the victim’s mobile device. Figure 1: Visualisation of the complete infection chain. Note: communication with the C2 server occurs during every malware stage. New features in Vultur The latest updates to Vultur bring some interesting changes worth discussing. The most intriguing addition is the malware’s ability to remotely interact with the infected device through the use of Android’s Accessibility Services. The malware operator can now send commands in order to perform clicks, scrolls, swipe gestures, and more. Firebase Cloud Messaging (FCM), a messaging service provided by Google, is used for sending messages from the C2 server to the infected device. The message sent by the malware operator through FCM can contain a command, which, upon receipt, triggers the execution of corresponding functionality within the malware. This eliminates the need for an ongoing connection with the device, as can be seen from the code snippet below. Figure 2: Decompiled code snippet showing Vultur’s ability to perform clicks and scrolls using Accessibility Services. Note for this (and upcoming) screenshot(s): some variables, classes and method names were renamed by the analyst. Pink strings indicate that they were decrypted. While Vultur can still maintain an ongoing remote connection with the device through the use of AlphaVNC and ngrok, the new Accessibility Services related FCM commands provide the actor with more flexibility. In addition to its more advanced remote control capabilities, Vultur introduced file manager functionality in the latest version. The file manager feature includes the ability to download, upload, delete, install, and find files. This effectively grants the actor(s) with even more control over the infected device. Figure 3: Decompiled code snippet showing part of the file manager related functionality. Another interesting new feature is the ability to block the victim from interacting with apps on the device. Regarding this functionality, the malware operator can specify a list of apps to press back on when detected as running on the device. The actor can include custom HTML code as a “template” for blocked apps. The list of apps to block and the corresponding HTML code to be displayed is retrieved through the vnc.blocked.packages C2 method. This is then stored in the app’s SharedPreferences. If available, the HTML code related to the blocked app will be displayed in a WebView after it presses back. If no HTML code is set for the app to block, it shows a default “Temporarily Unavailable” message after pressing back. For this feature, payload #3 interacts with code defined in payload #2. Figure 4: Decompiled code snippet showing part of Vultur’s implementation for blocking apps. The use of Android’s Accessibility Services to perform RAT related functionality (such as pressing back, performing clicks and swipe gestures) is something that is not new in Android malware. In fact, it is present in most Android bankers today. The latest features in Vultur show that its actors are catching up with this trend, and are even including functionality that is less common in Android RATs and bankers, such as controlling the device volume. A full list of Vultur’s updated and new C2 methods / FCM commands can be found in the “C2 Communication” section of this blog. Obfuscation techniques & detection evasion Like a crafty bird camouflaging its nest, Vultur now employs a set of new obfuscation and detection evasion techniques when compared to its previous versions. Let’s look into some of the notable updates that set apart the latest variant from older editions of Vultur. AES encrypted and Base64 encoded HTTPS traffic In October 2022, ThreatFabric mentioned that Brunhilda started using string obfuscation using AES with a varying key in the malware samples themselves [3]. At this point in time, both Brunhilda and Vultur did not encrypt its HTTP requests. That has changed now, however, with the malware developer’s adoption of AES encryption and Base64 encoding requests in the latest variants. Figure 5: Example AES encrypted and Base64 encoded request for bot registration. By encrypting its communications, malware can evade detection of security solutions that rely on inspecting network traffic for known patterns of malicious activity. The decrypted content of the request can be seen below. Note that the list of installed apps is shown as Base64 encoded text, as this list is encoded before encryption. {"id":"6500","method":"application.register","params":{"package":"com.wsandroid.suite","device":"Android/10","model":"samsung GT-I900","country":"sv-SE","apps":"cHQubm92b2JhbmNvLm5iYXBwO3B0LnNhbnRhbmRlcnRvdHRhLm1vYmlsZXBhcnRpY3VsYXJlcztzYS5hbHJhamhpYmFuay50YWh3ZWVsYXBwO3NhLmNvbS5zZS5hbGthaHJhYmE7c2EuY29tLnN0Y3BheTtzYW1zdW5nLnNldHRpbmdzLnBhc3M7c2Ftc3VuZy5zZXR0aW5ncy5waW47c29mdGF4LnBla2FvLnBvd2VycGF5O3RzYi5tb2JpbGViYW5raW5nO3VrLmNvLmhzYmMuaHNiY3VrbW9iaWxlYmFua2luZzt1ay5jby5tYm5hLmNhcmRzZXJ2aWNlcy5hbmRyb2lkO3VrLmNvLm1ldHJvYmFua29ubGluZS5tb2JpbGUuYW5kcm9pZC5wcm9kdWN0aW9uO3VrLmNvLnNhbnRhbmRlci5zYW50YW5kZXJVSzt1ay5jby50ZXNjb21vYmlsZS5hbmRyb2lkO3VrLmNvLnRzYi5uZXdtb2JpbGViYW5rO3VzLnpvb20udmlkZW9tZWV0aW5nczt3aXQuYW5kcm9pZC5iY3BCYW5raW5nQXBwLm1pbGxlbm5pdW07d2l0LmFuZHJvaWQuYmNwQmFua2luZ0FwcC5taWxsZW5uaXVtUEw7d3d3LmluZ2RpcmVjdC5uYXRpdmVmcmFtZTtzZS5zd2VkYmFuay5tb2JpbA==","tag":"dropper2"} Utilisation of legitimate package names The dropper is a modified version of the legitimate McAfee Security app. In order to masquerade malicious actions, it contains functionality that the official McAfee Security app would have. This has proven to be effective for the threat actors, as the dropper currently has a very low detection rate when analysed on VirusTotal. Figure 6: Brunhilda dropper’s detection rate on VirusTotal. Next to modding the legitimate McAfee Security app, Vultur uses the official Android Accessibility Suite package name for its Accessibility Service. This will be further discussed in the execution flow section of this blog. Figure 7: Snippet of Vultur’s AndroidManifest.xml file, where its Accessibility Service is defined with the Android Accessibility Suite package name. Leveraging native code for payload decryption Native code is typically written in languages like C or C++, which are lower-level than Java or Kotlin, the most popular languages used for Android application development. This means that the code is closer to the machine language of the processor, thus requiring a deeper understanding of lower-level programming concepts. Brunhilda and Vultur have started using native code for decryption of payloads, likely in order to make the samples harder to reverse engineer. Distributing malicious code across multiple payloads In this blog post we show how Brunhilda drops a total of 3 Vultur-related payloads: two APK files and one DEX file. We also showcase how payload #2 and #3 can effectively work together. This fragmentation can complicate the analysis process, as multiple components must be assembled to reveal the malware’s complete functionality. Execution flow: A three-headed… bird? While previous versions of Brunhilda delivered Vultur through a single payload, the latest variant now drops Vultur in three layers. The Brunhilda dropper in this campaign is a modified version of the legitimate McAfee Security app, which makes it seem harmless to the victim upon execution as it includes functionality that the official McAfee Security app would have. Figure 8: The modded version of the McAfee Security app is launched. In the background, the infected device registers with its C2 server through the /ejr/ endpoint and the application.register method. In the related HTTP POST request, the C2 is provided with the following information:

• Malware package name (as the dropper is a modified version of the McAfee Security app, it sends the official com.wsandroid.suite package name);
• Android version;
• Device model;
• Language and country code (example: sv-SE);
• Base64 encoded list of installed applications;
• Tag (dropper campaign name, example: dropper2).

The server response is decrypted and stored in a SharedPreference key named 9bd25f13-c3f8-4503-ab34-4bbd63004b6e, where the value indicates whether the registration was successful or not. After successfully registering the bot with the dropper C2, the first Vultur payload is eventually decrypted and installed from an onClick() method. Figure 9: Decryption and installation of the first Vultur payload. In this sample, the encrypted data is hidden in a file named 78a01b34-2439-41c2-8ab7-d97f3ec158c6 that is stored within the app’s “assets” directory. When decrypted, this will reveal an APK file to be installed. The decryption algorithm is implemented in native code, and reveals that it uses AES/ECB/PKCS5Padding to decrypt the first embedded file. The Lib.d() function grabs a substring from index 6 to 22 of the second argument (IPIjf4QWNMWkVQN21ucmNiUDZaVw==) to get the decryption key. The key used in this sample is: QWNMWkVQN21ucmNi (key varies across samples). With this information we can decrypt the 78a01b34-2439-41c2-8ab7-d97f3ec158c6 file, which brings us another APK file to examine: the first Vultur payload. Layer 1: Vultur unveils itself The first Vultur payload also contains the application.register method. The bot registers itself again with the C2 server as observed in the dropper sample. This time, it sends the package name of the current payload (se.accessibility.app in this example), which is not a modded application. The “tag” that was related to the dropper campaign is also removed in this second registration request. The server response contains an encrypted token for further communication with the C2 server and is stored in the SharedPreference key f9078181-3126-4ff5-906e-a38051505098. Figure 10: Decompiled code snippet that shows the data to be sent to the C2 server during bot registration. The main purpose of this first payload is to obtain Accessibility Service privileges and install the next Vultur APK file. Apps with Accessibility Service permissions can have full visibility over UI events, both from the system and from 3rd party apps. They can receive notifications, list UI elements, extract text, and more. While these services are meant to assist users, they can also be abused by malicious apps for activities, such as keylogging, automatically granting itself additional permissions, monitoring foreground apps and overlaying them with phishing windows. In order to gain further control over the infected device, this payload displays custom HTML code that contains instructions to enable Accessibility Services permissions. The HTML code to be displayed in a WebView is retrieved from the installer.config C2 method, where the HTML code is stored in the SharedPreference key bbd1e64e-eba3-463c-95f3-c3bbb35b5907. Figure 11: HTML code is loaded in a WebView, where the APP_NAME variable is replaced with the text “McAfee Master Protection”. In addition to the HTML content, an extra warning message is displayed to further convince the victim into enabling Accessibility Service permissions for the app. This message contains the text “Your system not safe, service McAfee Master Protection turned off. For using full device protection turn it on.” When the warning is displayed, it also sets the value of the SharedPreference key 1590d3a3-1d8e-4ee9-afde-fcc174964db4 to true. This value is later checked in the onAccessibilityEvent() method and the onServiceConnected() method of the malicious app’s Accessibility Service. ANALYST COMMENT
An important observation here, is that the malicious app is using the com.google.android.marvin.talkback package name for its Accessibility Service. This is the package name of the official Android Accessibility Suite, as can be seen from the following link: https://play.google.com/store/apps/details?id=com.google.android.marvin.talkback.
The implementation is of course different from the official Android Accessibility Suite and contains malicious code. When the Accessibility Service privileges have been enabled for the payload, it automatically grants itself additional permissions to install apps from unknown sources, and installs the next payload through the UpdateActivity. Figure 12: Decryption and installation of the second Vultur payload. The second encrypted APK is hidden in a file named data that is stored within the app’s “assets” directory. The decryption algorithm is again implemented in native code, and is the same as in the dropper. This time, it uses a different decryption key that is derived from the DXMgKBY29QYnRPR1k1STRBNTZNUw== string. The substring reveals the actual key used in this sample: Y29QYnRPR1k1STRB (key varies across samples). After decrypting, we are presented with the next layer of Vultur. Layer 2: Vultur descends The second Vultur APK contains more important functionality, such as AlphaVNC and ngrok setup, displaying of custom HTML code in WebViews, screen recording, and more. Just like the previous versions of Vultur, the latest edition still includes the ability to remotely access the infected device through AlphaVNC and ngrok. This second Vultur payload also uses the com.google.android.marvin.talkback (Android Accessibility Suite) package name for the malicious Accessibility Service. From here, there are multiple references to methods invoked from another file: the final Vultur payload. This time, the payload is not decrypted from native code. In this sample, an encrypted file named a.int is decrypted using AES/CFB/NoPadding with the decryption key SBhXcwoAiLTNIyLK (stored in SharedPreference key dffa98fe-8bf6-4ed7-8d80-bb1a83c91fbb). We have observed the same decryption key being used in multiple samples for decrypting payload #3. Figure 13: Decryption of the third Vultur payload. Furthermore, from payload #2 onwards, Vultur uses encrypted SharedPreferences for further hiding of malicious configuration related key-value pairs. Layer 3: Vultur strikes The final payload is a Dalvik Executable (DEX) file. This decrypted DEX file holds Vultur’s core functionality. It contains the references to all of the C2 methods (used in communication from bot to C2 server, in order to send or retrieve information) and FCM commands (used in communication from C2 server to bot, in order to perform actions on the infected device). An important observation here, is that code defined in payload #3 can be invoked from payload #2 and vice versa. This means that these final two files effectively work together. Figure 14: Decompiled code snippet showing some of the FCM commands implemented in Vultur payload #3. The last Vultur payload does not contain its own Accessibility Service, but it can interact with the Accessibility Service that is implemented in payload #2. C2 Communication: Vultur finds its voice When Vultur infects a device, it initiates a series of communications with its designated C2 server. Communications related to C2 methods such as application.register and vnc.blocked.packages occur using JSON-RPC 2.0 over HTTPS. These requests are sent from the infected device to the C2 server to either provide or receive information. Actual vultures lack a voice box; their vocalisations include rasping hisses and grunts [4]. While the communication in older variants of Vultur may have sounded somewhat similar to that, you could say that the threat actors have developed a voice box for the latest version of Vultur. The content of the aforementioned requests are now AES encrypted and Base64 encoded, just like the server response. Next to encrypted communication over HTTPS, the bot can receive commands via Firebase Cloud Messaging (FCM). FCM is a cross-platform messaging solution provided by Google. The FCM related commands are sent from the C2 server to the infected device to perform actions on it. During our investigation of the latest Vultur variant, we identified the C2 endpoints mentioned below. EndpointDescription/ejr/Endpoint for C2 communication using JSON-RPC 2.0.
Note: in older versions of Vultur the /rpc/ endpoint was used for similar communication./upload/Endpoint for uploading files (such as screen recording results)./version/app/?filename=ngrok&arch={DEVICE_ARCH}Endpoint for downloading the relevant version of ngrok./version/app/?filename={FILENAME}Endpoint for downloading a file specified by the payload (related to the new file manager functionality). C2 methods in Brunhilda dropper The commands below are sent from the infected device to the C2 server to either provide or receive information. MethodDescriptionapplication.registerRegisters the bot by providing the malware package name and information about the device: model, country, installed apps, Android version. It also sends a tag that is used for identifying the dropper campaign name.
Note: this method is also used once in Vultur payload #1, but without sending a tag. This method then returns a token to be used in further communication with the C2 server.application.stateSends a token value that was set as a response to the application.register command, together with a status code of “3”. C2 methods in Vultur The commands below are sent from the infected device to the C2 server to either provide or receive information. MethodDescriptionvnc.register (UPDATED)Registers the bot by providing the FCM token, malware package name and information about the device, model, country, Android version. This method has been updated in the latest version of Vultur to also include information on whether the infected device is rooted and if it is detected as an emulator.vnc.status (UPDATED)Sends the following status information about the device: if the Accessibility Service is enabled, if the Device Admin permissions are enabled, if the screen is locked, what the VNC address is. This method has been updated in the latest version of Vultur to also send information related to: active fingerprints on the device, screen resolution, time, battery percentage, network operator, location.vnc.appsSends the list of apps that are installed on the victim’s device.vnc.keylogSends the keystrokes that were obtained via keylogging.vnc.config (UPDATED)Obtains the config of the malware, such as the list of targeted applications by the keylogger and VNC. This method has been updated in the latest version of Vultur to also obtain values related to the following new keys: “packages2”, “rurl”, “recording”, “main_content”, “tvmq”.vnc.overlayObtains the HTML code for overlay injections of a specified package name using the pkg parameter. It is still unclear whether support for overlay injections is fully implemented in Vultur.vnc.overlay.logsSends the stolen credentials that were obtained via HTML overlay injections. It is still unclear whether support for overlay injections is fully implemented in Vultur.vnc.pattern (NEW)Informs the C2 server whether a PIN pattern was successfully extracted and stored in the application’s Shared Preferences.vnc.snapshot (NEW)Sends JSON data to the C2 server, which can contain:

1. Information about the accessibility event’s class, bounds, child nodes, UUID, event type, package name, text content, screen dimensions, time of the event, and if the screen is locked.
2. Recently copied text, and SharedPreferences values related to “overlay” and “keyboard”.
3. X and Y coordinates related to a click.vnc.submit (NEW)Informs the C2 server whether the bot registration was successfully submitted or if it failed.vnc.urls (NEW)Informs the C2 server about the URL bar related element IDs of either the Google Chrome or Firefox webbrowser (depending on which application triggered the accessibility event).vnc.blocked.packages (NEW)Retrieves a list of “blocked packages” from the C2 server and stores them together with custom HTML code in the application’s Shared Preferences. When one of these package names is detected as running on the victim device, the malware will automatically press the back button and display custom HTML content if available. If unavailable, a default “Temporarily Unavailable” message is displayed.vnc.fm (NEW)Sends file related information to the C2 server. File manager functionality includes downloading, uploading, installing, deleting, and finding of files.vnc.syslogSends logs.crash.logsSends logs of all content on the screen.installer.config (NEW)Retrieves the HTML code that is displayed in a WebView of the first Vultur payload. This HTML code contains instructions to enable Accessibility Services permissions. FCM commands in Vultur The commands below are sent from the C2 server to the infected device via Firebase Cloud Messaging in order to perform actions on the infected device. The new commands use IDs instead of names that describe their functionality. These command IDs are the same in different samples. CommandDescriptionregisteredReceived when the bot has been successfully registered.startStarts the VNC connection using ngrok.stopStops the VNC connection by killing the ngrok process and stopping the VNC service.unlockUnlocks the screen.deleteUninstalls the malware package.patternProvides a gesture/stroke pattern to interact with the device’s screen.109b0e16 (NEW)Presses the back button.18cb31d4 (NEW)Presses the home button.811c5170 (NEW)Shows the overview of recently opened apps.d6f665bf (NEW)Starts an app specified by the payload.1b05d6ee (NEW)Shows a black view.1b05d6da (NEW)Shows a black view that is obtained from the layout resources in Vultur payload #2.7f289af9 (NEW)Shows a WebView with HTML code loaded from SharedPreference key “946b7e8e”.dc55afc8 (NEW)Removes the active black view / WebView that was added from previous commands (after sleeping for 15 seconds).cbd534b9 (NEW)Removes the active black view / WebView that was added from previous commands (without sleeping).4bacb3d6 (NEW)Deletes an app specified by the payload.b9f92adb (NEW)Navigates to the settings of an app specified by the payload.77b58a53 (NEW)Ensures that the device stays on by acquiring a wake lock, disables keyguard, sleeps for 0,1 second, and then swipes up to unlock the device without requiring a PIN.ed346347 (NEW)Performs a click.5c900684 (NEW)Scrolls forward.d98179a8 (NEW)Scrolls backward.7994ceca (NEW)Sets the text of a specified element ID to the payload text.feba1943 (NEW)Swipes up.d403ad43 (NEW)Swipes down.4510a904 (NEW)Swipes left.753c4fa0 (NEW)Swipes right.b183a400 (NEW)Performs a stroke pattern on an element across a 3×3 grid.81d9d725 (NEW)Performs a stroke pattern based on x+y coordinates and time duration.b79c4b56 (NEW)Press-and-hold 3 times near bottom middle of the screen.1a7493e7 (NEW)Starts capturing (recording) the screen.6fa8a395 (NEW)Sets the “ShowMode” of the keyboard to 0. This allows the system to control when the soft keyboard is displayed.9b22cbb1 (NEW)Sets the “ShowMode” of the keyboard to 1. This means the soft keyboard will never be displayed (until it is turned back on).98c97da9 (NEW)Requests permissions for reading and writing external storage.7b230a3b (NEW)Request permissions to install apps from unknown sources.cc8397d4 (NEW)Opens the long-press power menu.3263f7d4 (NEW)Sets a SharedPreference value for the key “c0ee5ba1-83dd-49c8-8212-4cfd79e479c0” to the specified payload. This value is later checked for in other to determine whether the long-press power menu should be displayed (SharedPref value 1), or whether the back button must be pressed (SharedPref value 2).request_accessibility (UPDATED)Prompts the infected device with either a notification or a custom WebView that instructs the user to enable accessibility services for the malicious app. The related WebView component was not present in older versions of Vultur.announcement (NEW)Updates the value for the C2 domain in the SharedPreferences.5283d36d-e3aa-45ed-a6fb-2abacf43d29c (NEW)Sends a POST with the vnc.config C2 method and stores the malware config in SharedPreferences.09defc05-701a-4aa3-bdd2-e74684a61624 (NEW)Hides / disables the keyboard, obtains a wake lock, disables keyguard (lock screen security), mutes the audio, stops the “TransparentActivity” from payload #2, and displays a black view.fc7a0ee7-6604-495d-ba6c-f9c2b55de688 (NEW)Hides / disables the keyboard, obtains a wake lock, disables keyguard (lock screen security), mutes the audio, stops the “TransparentActivity” from payload #2, and displays a custom WebView with HTML code loaded from SharedPreference key “946b7e8e” (“tvmq” value from malware config).8eac269d-2e7e-4f0d-b9ab-6559d401308d (NEW)Hides / disables the keyboard, obtains a wake lock, disables keyguard (lock screen security), mutes the audio, stops the “TransparentActivity” from payload #2.e7289335-7b80-4d83-863a-5b881fd0543d (NEW)Enables the keyboard and unmutes audio. Then, sends the vnc.snapshot method with empty JSON data.544a9f82-c267-44f8-bff5-0726068f349d (NEW)Retrieves the C2 command, payload and UUID, and executes the command in a thread.a7bfcfaf-de77-4f88-8bc8-da634dfb1d5a (NEW)Creates a custom notification to be shown in the status bar.444c0a8a-6041-4264-959b-1a97d6a92b86 (NEW)Retrieves the list of apps to block and corresponding HTML code through the vnc.blocked.packages C2 method and stores them in the blocked_package_template SharedPreference key.a1f2e3c6-9cf8-4a7e-b1e0-2c5a342f92d6 (NEW)Executes a file manager related command. Commands are:

1. 91b4a535-1a78-4655-90d1-a3dcb0f6388a – Downloads a file
2. cf2f3a6e-31fc-4479-bb70-78ceeec0a9f8 – Uploads a file
3. 1ce26f13-fba4-48b6-be24-ddc683910da3 – Deletes a file
4. 952c83bd-5dfb-44f6-a034-167901990824 – Installs a file
5. 787e662d-cb6a-4e64-a76a-ccaf29b9d7ac – Finds files containing a specified pattern Detection Writing YARA rules to detect Android malware can be challenging, as APK files are ZIP archives. This means that extracting all of the information about the Android application would involve decompressing the ZIP, parsing the XML, and so on. Thus, most analysts build YARA rules for the DEX file. However, DEX files, such as Vultur payload #3, are less frequently submitted to VirusTotal as they are uncovered at a later stage in the infection chain. To maximise our sample pool, we decided to develop a YARA rule for the Brunhilda dropper. We discovered some unique hex patterns in the dropper APK, which allowed us to create the YARA rule below. rule brunhilda_dropper
{
meta:
author = "Fox-IT, part of NCC Group"
description = "Detects unique hex patterns observed in Brunhilda dropper samples."
target_entity = "file"
strings:
$zip_head = "PK"
$manifest = "AndroidManifest.xml"
$hex1 = {63 59 5c 28 4b 5f}
$hex2 = {32 4a 66 48 66 76 64 6f 49 36}
$hex3 = {63 59 5c 28 4b 5f}
$hex4 = {30 34 7b 24 24 4b}
$hex5 = {22 69 4f 5a 6f 3a}
condition:
$zip_head at 0 and $manifest and #manifest >= 2 and 2 of ($hex*)
} Wrap-up Vultur’s recent developments have shown a shift in focus towards maximising remote control over infected devices. With the capability to issue commands for scrolling, swipe gestures, clicks, volume control, blocking apps from running, and even incorporating file manager functionality, it is clear that the primary objective is to gain total control over compromised devices. Vultur has a strong correlation to Brunhilda, with its C2 communication and payload decryption having the same implementation in the latest variants. This indicates that both the dropper and Vultur are being developed by the same threat actors, as has also been uncovered in the past. Furthermore, masquerading malicious activity through the modification of legitimate applications, encryption of traffic, and the distribution of functions across multiple payloads decrypted from native code, shows that the actors put more effort into evading detection and complicating analysis. During our investigation of recently submitted Vultur samples, we observed the addition of new functionality occurring shortly after one another. This suggests ongoing and active development to enhance the malware’s capabilities. In light of these observations, we expect more functionality being added to Vultur in the near future. Indicators of Compromise Analysed samples Package nameFile hash (SHA-256)Descriptioncom.wsandroid.suiteedef007f1ca60fdf75a7d5c5ffe09f1fc3fb560153633ec18c5ddb46cc75ea21Brunhilda Droppercom.medical.balance89625cf2caed9028b41121c4589d9e35fa7981a2381aa293d4979b36cf5c8ff2Vultur payload #1com.medical.balance1fc81b03703d64339d1417a079720bf0480fece3d017c303d88d18c70c7aabc3Vultur payload #2com.medical.balance4fed4a42aadea8b3e937856318f9fbd056e2f46c19a6316df0660921dd5ba6c5Vultur payload #3com.wsandroid.suite001fd4af41df8883957c515703e9b6b08e36fde3fd1d127b283ee75a32d575fcBrunhilda Dropperse.accessibility.appfc8c69bddd40a24d6d28fbf0c0d43a1a57067b19e6c3cc07e2664ef4879c221bVultur payload #1se.accessibility.app7337a79d832a57531b20b09c2fc17b4257a6d4e93fcaeb961eb7c6a95b071a06Vultur payload #2se.accessibility.app7f1a344d8141e75c69a3c5cf61197f1d4b5038053fd777a68589ecdb29168e0cVultur payload #3com.wsandroid.suite26f9e19c2a82d2ed4d940c2ec535ff2aba8583ae3867502899a7790fe3628400Brunhilda Droppercom.exvpn.fastvpn2a97ed20f1ae2ea5ef2b162d61279b2f9b68eba7cf27920e2a82a115fd68e31fVultur payload #1com.exvpn.fastvpnc0f3cb3d837d39aa3abccada0b4ecdb840621a8539519c104b27e2a646d7d50dVultur payload #2com.wsandroid.suite92af567452ecd02e48a2ebc762a318ce526ab28e192e89407cac9df3c317e78dBrunhilda Dropperjk.powder.tendencefa6111216966a98561a2af9e4ac97db036bcd551635be5b230995faad40b7607Vultur payload #1jk.powder.tendencedc4f24f07d99e4e34d1f50de0535f88ea52cc62bfb520452bdd730b94d6d8c0eVultur payload #2jk.powder.tendence627529bb010b98511cfa1ad1aaa08760b158f4733e2bbccfd54050838c7b7fa3Vultur payload #3com.wsandroid.suitef5ce27a49eaf59292f11af07851383e7d721a4d60019f3aceb8ca914259056afBrunhilda Dropperse.talkback.app5d86c9afd1d33e4affa9ba61225aded26ecaeb01755eeb861bb4db9bbb39191cVultur payload #1se.talkback.app5724589c46f3e469dc9f048e1e2601b8d7d1bafcc54e3d9460bc0adeeada022dVultur payload #2se.talkback.app7f1a344d8141e75c69a3c5cf61197f1d4b5038053fd777a68589ecdb29168e0cVultur payload #3com.wsandroid.suitefd3b36455e58ba3531e8cce0326cce782723cc5d1cc0998b775e07e6c2622160Brunhilda Droppercom.adajio.storm819044d01e8726a47fc5970efc80ceddea0ac9bf7c1c5d08b293f0ae571369a9Vultur payload #1com.adajio.storm0f2f8adce0f1e1971cba5851e383846b68e5504679d916d7dad10133cc965851Vultur payload #2com.adajio.stormfb1e68ee3509993d0fe767b0372752d2fec8f5b0bf03d5c10a30b042a830ae1aVultur payload #3com.protectionguard.appd3dc4e22611ed20d700b6dd292ffddbc595c42453f18879f2ae4693a4d4d925aBrunhilda Dropper (old variant)com.appsmastersafeyf4d7e9ec4eda034c29b8d73d479084658858f56e67909c2ffedf9223d7ca9bd2Vultur (old variant)com.datasafeaccountsanddata.club7ca6989ccfb0ad0571aef7b263125410a5037976f41e17ee7c022097f827bd74Vultur (old variant)com.app.freeguarding.twofactorc646c8e6a632e23a9c2e60590f012c7b5cb40340194cb0a597161676961b4de0Vultur (old variant) Note: Vultur payloads #1 and #2 related to Brunhilda dropper 26f9e19c2a82d2ed4d940c2ec535ff2aba8583ae3867502899a7790fe3628400 are the same as Vultur payloads #2 and #3 in the latest variants. The dropper in this case only drops two payloads, where the latest versions deploy a total of three payloads. C2 servers

• safetyfactor[.]online
• cloudmiracle[.]store
• flandria171[.]appspot[.]com (FCM)
• newyan-1e09d[.]appspot[.]com (FCM)

Dropper distribution URLs

• mcafee[.]960232[.]com
• mcafee[.]353934[.]com
• mcafee[.]908713[.]com
• mcafee[.]784503[.]com
• mcafee[.]053105[.]com
• mcafee[.]092877[.]com
• mcafee[.]582630[.]com
• mcafee[.]581574[.]com
• mcafee[.]582342[.]com
• mcafee[.]593942[.]com
• mcafee[.]930204[.]com

References

1. https://resources.prodaft.com/brunhilda-daas-malware-report ︎
2. https://www.threatfabric.com/blogs/vultur-v-for-vnc ︎
3. https://www.threatfabric.com/blogs/the-attack-of-the-droppers ︎
4. https://www.wildlifecenter.org/vulture-facts ︎

Additive manufacturing (AM) engineers have been incredibly creative in developing ancillary systems that modify a printed parts mechanical properties.  These systems mostly focus on the issue of anisotropic properties of additively built components.  This blog post is a good reference if you are unfamiliar with isotropic vs anisotropic properties and how they impact 3d printing.  […] The post Cybersecurity Concerns for Ancillary Strength Control Subsystems appeared first on BreakPoint Labs - Blog.

To consolidate all of our security intelligence and news in one location, we have migrated Naked Security to the Sophos News platform.