By Deeba Ahmed
esearchers have labeled this as the "ultimate cryptominer."
This is a post from HackRead.com Read the original post: Microsoft Azure Exploited to Create Undetectable Cryptominer

SafeBreach Labs’ researchers have successfully exploited MS Azure Automation Service to develop the first Free and Undetectable Cryptocurrency miner.

**Cryptomining** can cause harm if someone unauthorized does it on a regular person’s device. SafeBreach Labs found that researchers can use trustworthy, widely-used software to mine cryptocurrency without using many resources or incurring costs.

In a report shared with _Hackread.com_ ahead of publication on Wednesday, SafeBreach researchers demonstrated this by creating the first completely undetectable cryptominer that operates freely using Microsoft Azure’s Automation service. This service is specifically made to automate cloud-management tasks, eliminating the need for building or maintaining infrastructure. Users only need to provide the scripts for execution.

In a blog post by Ariel Gamrian, three methods for running a cryptocurrency miner on **Microsoft Azure** servers without detection or charges were discovered. SafeBreach Labs’ researchers referred to this as the ultimate cryptominer.

They found that the Azure automation service allows the uploading of custom Python packages, which are then utilized within the runbook scripts. Whenever a package is uploaded, the service silently installs it in the background to ensure successful installation and prevent runbook execution problems. The researchers from SafeBreach Labs exploited this behaviour to develop the cryptominer successfully.

“We knew that code could not be directly executed on a .whl file installation, but we could assume what command was used in the background for installation. We assumed the .whl file would be installed by the pip executable already installed in the Automation Account using the command “pip install “pip install <whl\_file>,” **explained** Gamrian.

“If our assumptions were correct, we could create a malicious package named “pip” and upload it to the Automation Account. The upload flow would replace the current pip in the Automation account.”

Once the custom pip was stored in the Automation account, the service automatically employed it whenever a package was uploaded. Leveraging this flow, the researchers managed to execute code. They ran this in a temporary sandboxed environment, obtaining an access token that represented the Automation Account’s assigned identity. This token allowed them to make requests on behalf of that identity, almost entirely obscuring any trace back to them.

Additionally, researchers found that they could achieve code execution by utilizing the Powershell module upload flow. This involved creating a Powershell module file containing the desired code for upload. While exploring the pricing, they discovered that the feature’s pricing details were not documented.

To determine the cost, they had to manually identify the code runtime and the associated flow cost. To test this, they initiated 55 import flows simultaneously, which theoretically accounted for approximately 10,000 minutes of runtime considering the three-hour import flow limitation.

A short demo about package upload shared by SafeBreach

After a month, they checked and found they were not charged anything, confirming that their developed cryptominer incurred no charges and was maintenance-free. Subsequently, they developed a tool named CloudMiner, enabling anyone to execute code for free on Azure using the same technique. Users only need to provide the Python or Powershell script they wish to execute and grant access to their Automation Account, and the tool will manage the rest.

CloudMiner in action (SafeBreach)

This research could significantly impact not only **crypto mining** but also other domains requiring code execution on Azure. Users can obtain cryptocurrency through various means, such as online exchanges, as payment, or by mining virtually.

Mining is a favoured method for earning crypto, involving a network of computers that verify and secure blockchains and digital ledgers recording crypto transactions. Miners are rewarded with new coins within this self-sustaining cycle, making it a preferred avenue for scammers.

The researchers reported their findings to the Microsoft Security Response Center, but no Common Vulnerabilities and Exposures (**CVEs**) were issued. However, the software company acknowledged the issue in their Security Researcher Acknowledgements for Microsoft Online Services. Subsequently, they addressed and resolved the Python 3.10 free runtime issue.

****_RELATED ARTICLES_****

1.  **Mirai botnet exploiting Azure OMIGOD vulnerabilities**
2.  **Sensitive source codes exposed in Microsoft Azure Blob account leak**
3.  **Researchers accessed primary keys of Azure’s Cosmos DB customers**
4.  **SolarWinds hackers accessed source code of Azure, Exchange, Intune**
5.  **240 top Microsoft Azure-hosted subdomains hacked to spread malware**
6.  **CISA’s Sparrow.ps1 tool detects malicious activity on Azure, Microsoft 365**

Microsoft Azure Exploited to Create Undetectable Cryptominer

Cybersecurity researchers have developed what's the first fully undetectable cloud-based cryptocurrency miner leveraging the Microsoft Azure Automation service without racking up any charges.
Cybersecurity company SafeBreach said it discovered three different methods to run the miner, including one that can be executed on a victim's environment without attracting any attention.
"While this

Cloud Security / Cryptocurrency

Cybersecurity researchers have developed what's the first fully undetectable cloud-based cryptocurrency miner leveraging the Microsoft Azure Automation service without racking up any charges.

Cybersecurity company SafeBreach said it discovered three different methods to run the miner, including one that can be executed on a victim's environment without attracting any attention.

"While this research is significant because of its potential impact on cryptocurrency mining, we also believe it has serious implications for other areas, as the techniques could be used to achieve any task that requires code execution on Azure," security researcher Ariel Gamrian said in a report shared with The Hacker News.

The study mainly set out to identify an "ultimate crypto miner" that offers unlimited access to computational resources, while simultaneously requiring little-to-no maintenance, is cost-free, and undetectable.

That's where Azure Automation comes in. Developed by Microsoft, it's a cloud-based automation service that allows users to automate the creation, deployment, monitoring, and maintenance of resources in Azure.

SafeBreach said it found a bug in the Azure pricing calculator that made it possible to execute an infinite number of jobs totally free of charge, although it relates to the attacker's environment itself. Microsoft has since issued a fix for the problem.

An alternative method entails creating a test-job for mining, followed by setting its status as "Failed," and then creating another dummy test-job by taking advantage of the fact that only one test can run at the same time.

The end result of this flow is that it completely hides code execution within the Azure environment.

A threat actor could leverage these methods by establishing a reverse shell towards an external server and authenticating to the Automation endpoint to achieve their goals.

Furthermore, it was found that code execution could be achieved by leveraging Azure Automation's feature that allows users to upload custom Python packages.

"We could create a malicious package named 'pip' and upload it to the Automation Account," Gamrian explained.

"The upload flow would replace the current pip in the Automation account. After our custom pip was saved in the Automation account, the service used it every time a package was uploaded."

SafeBreach has also made available a proof-of-concept dubbed CoinMiner that's designed to get free computing power within Azure Automation service by using the Python package upload mechanism.

Microsoft, in response to the disclosures, has characterized the behavior as "by design," meaning the method can still be exploited without getting charged.

While the scope of the research is limited to the abuse of Azure Automation for cryptocurrency mining, the cybersecurity firm warned that the same techniques could be repurposed by threat actors to achieve any task that requires code execution on Azure.

"As cloud provider customers, individual organizations must proactively monitor every single resource and every action being performed within their environment," Gamrian said.

"We highly recommend that organizations educate themselves about the methods and flows malicious actors may use to create undetectable resources and proactively monitor for code execution indicative of such behavior."

Found this article interesting? Follow us on Twitter __ and LinkedIn to read more exclusive content we post.

Researchers Uncover Undetectable Crypto Mining Technique on Azure Automation

A new set of malicious Python packages has slithered their way to the Python Package Index (PyPI) repository with the ultimate aim of stealing sensitive information from compromised developer systems.
The packages masquerade as seemingly innocuous obfuscation tools, but harbor a piece of malware called BlazeStealer, Checkmarx said in a report shared with The Hacker News.
"[BlazeStealer]

Supply Chain / Software Security

A new set of malicious Python packages has slithered their way to the Python Package Index (PyPI) repository with the ultimate aim of stealing sensitive information from compromised developer systems.

The packages masquerade as seemingly innocuous obfuscation tools, but harbor a piece of malware called **BlazeStealer**, Checkmarx said in a report shared with The Hacker News.

"\[BlazeStealer\] retrieves an additional malicious script from an external source, enabling a Discord bot that gives attackers complete control over the victim's computer," security researcher Yehuda Gelb said.

The campaign, which commenced in January 2023, entails a total of eight packages named Pyobftoexe, Pyobfusfile, Pyobfexecute, Pyobfpremium, Pyobflite, Pyobfadvance, Pyobfuse, and pyobfgood, the last of which was published in October.

These modules come with setup.py and init.py files that are designed to retrieve a Python script hosted on transfer\[.\]sh, which gets executed immediately upon their installation.

Called BlazeStealer, the malware runs a Discord bot and enables the threat actor to harvest a wide range of information, including passwords from web browsers and screenshots, execute arbitrary commands, encrypt files, and deactivate Microsoft Defender Antivirus on the infected host.

What's more, it can render the computer unusable by ramping up CPU usage, inserting a Windows Batch script in the startup directory to shut down the machine, and even forcing a blue screen of death (BSoD) error.

"It stands to reason that developers engaged in code obfuscation are likely dealing with valuable and sensitive information, and therefore, to a hacker, this translates to a target worth pursuing," Gelb noted.

A majority of downloads associated with the rogue packages originated from the U.S., followed by China, Russia, Ireland, Hong Kong, Croatia, France, and Spain. They were collectively downloaded 2,438 times before being taken down.

"The open-source domain remains a fertile ground for innovation, but it demands caution," Gelb said. "Developers must remain vigilant, and vet the packages prior to consumption."

Found this article interesting? Follow us on Twitter __ and LinkedIn to read more exclusive content we post.

Beware, Developers: BlazeStealer Malware Discovered in Python Packages on PyPI

Improper Restriction of Excessive Authentication Attempts vulnerability in Samsung Smart TV UE40D7000 version T-GAPDEUC-1033.2 and before allows attackers to cause a denial of service via WPS attack tools.

CVE-2023-41270: SMOLD TV: Old & Smart

Videolan VLC prior to version 3.0.20 contains an Integer underflow that leads to an incorrect packet length.

**Background**

In VLC, IO (network stream protocols and more) is done under modules/access.

There is an old protocol called MMS (Microsoft media server) - MMS Wiki

There are two implementations used by VLC - MMST (MMS over TCP) and MMSH (MMS over HTTP).

**Packets**

According to the logic in the VLC code, the packets are in the following formats:

2 bytes

2 bytes

4 bytes

2 bytes

2 bytes

n bytes

i_type

i_size

i_sequence

i_unknown

i_size2

data

**Issues****GetPacket - Heap overflow**

Packets are received in GetPacket:

    static int GetPacket( stream_t * p_access, chunk_t *p_ck )
    {
        access_sys_t *p_sys = p_access->p_sys;
        int restsize;
        /* chunk_t */
        memset( p_ck, 0, sizeof( chunk_t ) );
        /* Read the chunk header */
        /* Some headers are short, like 0x4324. Reading 12 bytes will cause us
         * to lose synchronization with the stream. Just read to the length
         * (4 bytes), decode and then read up to 8 additional bytes to get the
         * entire header.
         */
        if( vlc_tls_Read( p_sys->stream, p_sys->buffer, 4, true ) < 4 )
        {
           msg_Err( p_access, "cannot read data 2" );
           return VLC_EGENERIC;
        }
        p_ck->i_type = GetWLE( p_sys->buffer);
        p_ck->i_size = GetWLE( p_sys->buffer + 2);
        restsize = p_ck->i_size;
        if( restsize > 8 )
            restsize = 8;
        if( vlc_tls_Read( p_sys->stream, p_sys->buffer + 4, restsize, true ) < restsize )
        {
            msg_Err( p_access, "cannot read data 3" );
            return VLC_EGENERIC;
        }
        p_ck->i_sequence  = GetDWLE( p_sys->buffer + 4);
        p_ck->i_unknown   = GetWLE( p_sys->buffer + 8);
        /* Set i_size2 to 8 if this header was short, since a real value won't be
         * present in the buffer. Using 8 avoid reading additional data for the
         * packet.
         */
        if( restsize < 8 )
            p_ck->i_size2 = 8;
        else
            p_ck->i_size2 = GetWLE( p_sys->buffer + 10);
        p_ck->p_data      = p_sys->buffer + 12;
        p_ck->i_data      = p_ck->i_size2 - 8;
        if( p_ck->i_type == 0x4524 )   // $E (End-of-Stream Notification) Packet
        {
            if( p_ck->i_sequence == 0 )
            {
                msg_Warn( p_access, "EOF" );
                return VLC_EGENERIC;
            }
            else
            {
                msg_Warn( p_access, "next stream following" );
                return VLC_EGENERIC;
            }
        }
        else if( p_ck->i_type == 0x4324 ) // $C (Stream Change Notification) Packet
        {
            /* 0x4324 is CHUNK_TYPE_RESET: a new stream will follow with a sequence of 0 */
            msg_Warn( p_access, "next stream following (reset) seq=%d", p_ck->i_sequence  );
            return VLC_EGENERIC;
        }
        else if( (p_ck->i_type != 0x4824) && (p_ck->i_type != 0x4424) )
        {
            /* Unsupported so far:
             * $M (Metadata) Packet               0x4D24
             * $P (Packet-Pair) Packet            0x5024
             * $T (Test Data Notification) Packet 0x5424
             */
            msg_Err( p_access, "unrecognized chunk FATAL (0x%x)", p_ck->i_type );
            return VLC_EGENERIC;
        }
        if( (p_ck->i_data > 0) &&
            (vlc_tls_Read( p_sys->stream, &p_sys->buffer[12], p_ck->i_data,
                           true ) < p_ck->i_data) )
        {
            msg_Err( p_access, "cannot read data 4" );
            return VLC_EGENERIC;
        }
    #if 0
        if( (p_sys->i_packet_sequence != 0) &&
            (p_ck->i_sequence != p_sys->i_packet_sequence) )
        {
            msg_Warn( p_access, "packet lost ? (%d != %d)", p_ck->i_sequence, p_sys->i_packet_sequence );
        }
    #endif
        p_sys->i_packet_sequence = p_ck->i_sequence + 1;
        p_sys->i_packet_used   = 0;
        p_sys->i_packet_length = p_ck->i_data;
        p_sys->p_packet        = p_ck->p_data;
        return VLC_SUCCESS;
    }
    

We can see that there are 3 sequence of data receival:

1.  We receive 4 bytes which of type and i_size which describe the size of the next read (capped to 8).
2.  We receive 8 bytes which are the rest of the header: i_sequence, i_unknown and i_size2 which is the total size of the packet (including the headers and data).
3.  Reading the data.

The issue is that when they calculate the remaining size of the packet to read:

    p_ck->i_data = p_ck->i_size2 - 8;
    

Instead of decreasing 12 (which is the size of the already read headers), they only decrease 8.

later on, i_data bytes is going to be read from the socket into the buffer p_ck->p_data at:

        if( (p_ck->i_data > 0) &&
            (vlc_tls_Read( p_sys->stream, &p_sys->buffer[12], p_ck->i_data,
                           true ) < p_ck->i_data) )
        {
            msg_Err( p_access, "cannot read data 4" );
            return VLC_EGENERIC;
        }
    

And as we can see, it’s being read into offset 12 of the buffer.

The size being read is capped to i_size2 = 0xffff - 8 = 0xfff7, so if the buffer size is less then 0xfff7 + 0xc = 0x10003 we’ll get an overflow.

Looking at the struct which contains the buffer we can see the size:

    #define BUFFER_SIZE 65536
    typedef struct
    {
        int             i_proto;
        struct vlc_tls *stream;
        vlc_url_t       url;
        bool      b_proxy;
        vlc_url_t       proxy;
        int             i_request_context;
        uint8_t         buffer[BUFFER_SIZE + 1];
        bool      b_broadcast;
        uint8_t         *p_header;
        int             i_header;
        uint8_t         *p_packet;
        uint32_t        i_packet_sequence;
        unsigned int    i_packet_used;
        unsigned int    i_packet_length;
        uint64_t        i_start;
        uint64_t        i_position;
        asf_header_t    asfh;
        vlc_guid_t          guid;
    } access_sys_t;
    

This struct is located on the heap, and the buffer size is 65536 + 1 = 0x10001 which is smaller. Hence we get an heap overflow.

**Showcase**

I compiled VLC myself using the following guidelines to get debug symbols.

Implemented a basic MMSH server which get’s to the first time GetPacket is being called (Describe->GetHeader->GetPacket),

passes the checks and send 0xffff bytes of ‘A’ (0x41) as the packet data, by setting a break point after reading the data (read 4),

we get the following (using gdb):

As we can see buffer is filled by a lot of A’s (0x41), and that the next struct field b_broadcast is set to 65 which is 0x41 - ‘A’, which confirms our assumption.

**GetPacket - integer underflow**

When calculating the data size, we already saw the following line:

    p_ck->i_data      = p_ck->i_size2 - 8;
    

Since we control i_size2 we think this might cause an underflow. Now, looking at the definitions of i_data and i_size2 in the chunk_t struct:

    typedef struct
    {
        uint16_t i_type;
        uint16_t i_size;
    
        uint32_t i_sequence;
        uint16_t i_unknown;
    
        uint16_t i_size2;
    
        int      i_data;
        uint8_t  *p_data;
    
    } chunk_t;
    

We can see that i_data is int, and i_size2 is uint16_t.

Normally, copying any value of uint16 to int is fine, since the value is zero-extended by default.

However, when we decrement 8, the order of the subtraction is important, since, if we:

1.  Copy the uint16 to the int.
2.  Substract 8. We might get an int underflow. this is confirmed by the dissasembly (using IDA) of the relevant function:

*   r11d is the lower dword of r11 register.
*   rbp+174 is the address of the local variable containing i_size2.

And we can see that the uint16 value is first copied (zero-extended) into r11d, and only then we subtract 8 from r11d.

This is not very useful as of the moment, since the following sanity checks validates that i_data > 0:

        if( (p_ck->i_data > 0) &&
            (vlc_tls_Read( p_sys->stream, &p_sys->buffer[12], p_ck->i_data,
                           true ) < p_ck->i_data) )
        {
            msg_Err( p_access, "cannot read data 4" );
            return VLC_EGENERIC;
        }
    

However, the value of i_data is being written to p_sys->i_packet_length:

        p_sys->i_packet_length = p_ck->i_data;
    

Which might be useful somewhere else, I didn’t verify this bug using my custom server + gdb.

**Responsible disclosure**

1/09/2023 - Contacted VLC security and reported both issues.

7/09/2023 - Got a response recognizing the issues.

30/10/2023 - VLC team update that a fixed was issued and tagged 3.0.20

31/10/2023 - Published the findings and submitted a CVE.

CVE-2023-47360: VLC 3.0.13 - MMS Stream bugs

The Pakistan-linked threat actor known as SideCopy has been observed leveraging the recent WinRAR security vulnerability in its attacks targeting Indian government entities to deliver various remote access trojans such as AllaKore RAT, Ares RAT, and DRat.
Enterprise security firm SEQRITE described the campaign as multi-platform, with the attacks also designed to infiltrate Linux systems with a

The Pakistan-linked threat actor known as **SideCopy** has been observed leveraging the recent WinRAR security vulnerability in its attacks targeting Indian government entities to deliver various remote access trojans such as AllaKore RAT, Ares RAT, and DRat.

Enterprise security firm SEQRITE described the campaign as multi-platform, with the attacks also designed to infiltrate Linux systems with a compatible version of Ares RAT.

SideCopy, active since at least 2019, is known for its attacks on Indian and Afghanistan entities. It's suspected to be a sub-group of the Transparent Tribe (ak APT36).

"Both SideCopy and APT36 share infrastructure and code to aggressively target India," SEQRITE researcher Sathwik Ram Prakki said in a Monday report.

Earlier this May, the group was linked to a phishing campaign that took advantage of lures related to India's Defence Research and Development Organization (DRDO) to deliver information-stealing malware.

Since then, SideCopy has also been implicated in a set of phishing attacks targeting the Indian defense sector with ZIP archive attachments to propagate Action RAT and a new .NET-based trojan that supports 18 different commands.

The new phishing campaigns detected by SEQRITE entail two different attack chains, each targeting Linux and Windows operating systems.

The former revolves around a Golang-based ELF binary that paves the way for a Linux version of Ares RAT that's capable of enumerating files, taking screenshots, and file downloading and uploading, among others.

The second campaign, on the other hand, entails the exploitation of CVE-2023-38831, a security flaw in the WinRAR archiving tool, to trigger the execution of malicious code, leading to the deployment of AllaKore RAT, Ares RAT, and two new trojans called DRat and Key RAT.

"\[AllaKore RAT\] has the functionality to steal system information, keylogging, take screenshots, upload & download files, and take the remote access of the victim machine to send commands and upload stolen data to the C2," Ram Prakki said.

DRat is capable of parsing as many as 13 commands from the C2 server to gather system data, download and execute additional payloads, and perform other file operations.

The targeting of Linux is not coincidental and is likely motivated by India's decision to replace Microsoft Windows with a Linux flavor called Maya OS across government and defense sectors.

"Expanding its arsenal with zero-day vulnerability, SideCopy consistently targets Indian defense organizations with various remote access trojans," Ram Prakki said.

"APT36 is expanding its Linux arsenal constantly, where sharing its Linux stagers with SideCopy is observed to deploy an open-source Python RAT called Ares."

Found this article interesting? Follow us on Twitter __ and LinkedIn to read more exclusive content we post.

SideCopy Exploiting WinRAR Flaw in Attacks Targeting Indian Government Entities

Microsoft Edge (Chromium-based) Information Disclosure Vulnerability

CVE-2023-36409

CVE-2023-36769

By Waqas
Some of the most prominent victims of the data breach include Cloudflare, 1Password, and BeyondTrust.
This is a post from HackRead.com Read the original post: Okta Breach Linked to Employee’s Google Account, Affects 134 Customers

Okta’s investigation determined the breach to be associated with a Google account belonging to one of the company’s employees.

In a recent update following the initial data breach announcement made in October 2023, Okta, a prominent identity and access management (IAM) provider, disclosed that the number of affected customers has now reached 134. This breach enabled threat actors to gain unauthorized access to files.

“Some of these files were HAR files that contained session tokens which could in turn be used for session hijacking attacks,” David Bradbury, Okta’s chief security officer explained in Friday’s November 4th update.

Between September 28 and October 17, 2023, Okta encountered a sophisticated attack, wherein a threat actor accessed Okta’s support case management system by compromising a stolen account. Afterwards, the threat actor gained the ability to view, update support cases, and extract sensitive data, which included session tokens.

On October 19, Okta became aware of the breach following a notification from one of its customers, BeyondTrust, regarding suspicious activities. Among the prominent customers affected by the breach are Cloudflare and 1Password. Pedro Canahuati, the CTO of 1Password, disclosed the incident, confirming that threat actors were unable to access or extract user data during the attack.

****Google Account Connection****

Originally, the incident was thought to occur as a threat actor accessed an IT employee’s Okta session token by leveraging a stolen credential, thus gaining entry into 1Password’s Okta administrative portal. However, Bradbury later revealed that the investigation determined the breach to be associated with a Google account belonging to one of the company’s employees.

“Okta Security identified that an employee had signed-in to their personal Google profile on the Chrome browser of their Okta-managed laptop,” Bradbury said. “The username and password of the service account had been saved into the employee’s personal Google account. The most likely avenue for exposure of this credential is the compromise of the employee’s personal Google account or personal device.”

As to why it took two weeks for Okta to address the issue, Bradbury further explained that “Okta didn’t find any suspicious downloads in their system logs.” They noted that when someone looks at files attached to a support case, there’s a special record in their logs. But if a person goes directly to the Files section in the customer support system, it creates a different record. The attackers used this method in their attack.

“Okta first looked into access to support cases and then checked the logs related to those cases. On October 13, 2023, BeyondTrust gave Okta Security an IP address linked to the attackers. With this information, Okta found more file access events tied to the compromised account,” said Bradbury.

In a comment to Hackread.com, Tal Skverer, Research Team Lead at Astrix Security, discussed the use of personal accounts on devices issued by the company stating that “Service accounts skip security measures that normal accounts are subject to, such as MFA, therefore; their credentials are extremely vulnerable.”

“It is with utmost importance that service accounts follow the least privilege principle. Skverer emphasised. “To limit their permissions, their usage should be limited to very unique functionalities.”

The Okta breach is a major concern for the cybersecurity community, as Okta is a trusted IAM provider for many organizations, including Fortune 500 companies and government agencies. The breach also highlights the growing sophistication of threat actors and the need for organizations to take steps to protect their data from increasingly targeted attacks.

Nevertheless, the latest security breach at Okta serves as the second cyberattack on the company. In March 2022, LAPSUS$ hackers claimed to have breached Okta and Microsoft after leaking a trove of their data on Telegram.

****What Organizations Can Do to Protect Themselves****

Organizations can take a number of steps to protect themselves, including:

*   **Implement strong password policies and require users to use multi-factor authentication (MFA).** MFA adds an extra layer of security to user accounts by requiring users to provide a second form of authentication, such as a code from their phone, in addition to their password.
*   **Regularly update security software and patches.** Software developers release security updates to patch known vulnerabilities. By regularly updating their software and patches, organizations can help to reduce the risk of being exploited by attackers.
*   **Educate employees about cybersecurity best practices.** Employees should be trained on how to identify and avoid phishing attacks, and how to protect their devices and data.
*   **Monitor their systems for suspicious activity.** Organizations should have systems in place to monitor their systems for suspicious activity, such as unusual login attempts or data exfiltration.

1.  IBM Notifies Janssen CarePath Customers of Data Breach
2.  Human Error: Casio ClassPad Data Breach Impacting 148 Countries
3.  Sony Data Breach via MOVEit Vulnerability Affects Thousands in US
4.  Fake Bitwarden Password Manager Website Drops Windows ZenRAT
5.  Kroll SIM-Swapping Attack Causes Data Breach at 3 Top Crypto Firms
6.  Passwords by Kaspersky Password Manager exposed to brute-force attack

Okta Breach Linked to Employee’s Google Account, Affects 134 Customers

By Waqas
After a surge of malware on the Google Play Store, is Microsoft also failing to properly vet apps for malware?
This is a post from HackRead.com Read the original post: Scammers Use Fake Ledger App on Microsoft Store to Steal $800,000 in Crypto

The fake Ledger Live app on the Microsoft Store deceived users into downloading malware, which stole their Bitcoin and Ethereum funds.

Hackread.com has been actively following the cryptocurrency space as it has lately been a prominent target of scams and cyberattacks. Hackers are eyeing the crypto industry to steal valuable assets and even NFTs.

For this purpose, crooks devise clever tactics to lure unsuspecting users into giving away their funds and tokens. One such scam was recently reported by a pseudonymous on-chain detective and crypto sleuth, ZachXBT. 

According to ZachXBT, a fake Ledger app was circulating on the Microsoft App Store. This fraudulent app masqueraded as the official Ledger Live app and tricked users into unwittingly downloading and installing malware stealing victims’ crypto funds and data.

Fake Ledger app on Microsoft Store (Screenshot: ZachXBT)

ZachXBT’s analysis stressed the sophisticated nature of this scam, emphasizing the critical need for end-users to stay alert in protecting their cryptocurrency wallets. As of November 4th, scammers successfully collected roughly $588,000 in Bitcoin by hijacking users’ crypto wallets.

In a tweet, ZachXBT cautioned crypto users and investors with the following warning: “Community Alert: There is currently a fake @Ledger Live app on the official @Microsoft App Store which was resulted in 16.8+ BTC ($588K) stolen.”

However, on November 5th, ZachXBT received updated information from a victim, indicating a loss of $180,000 worth of ETH due to the fake Ledger app. This significantly increased the total lost payments to over $768,000.

Stolen funds (Screenshot: Hackread.com)

It is worth noting that in November 2023, a fake Ledger Live app was uploaded to the official Microsoft App Store that looked exactly like the original Ledger Live app. For your information, it is a popular software wallet designed to help users manage their crypto assets.

However, those who downloaded the fake version of this app ended up installing malware capable of stealing cryptocurrency by intercepting users’ recovery phrases. The attackers specifically targeted users who store their cryptocurrency in the Ledger hardware wallets to profit by stealing their assets.

The attackers designed the fake app quite cunningly, replicating the look and features of the authentic app, including identical logos and branding materials. They went as far as creating a fraudulent Ledger device pin verification process. This tricky similarity between the original and fake apps makes it challenging for users to differentiate between them.

Nevertheless, Microsoft promptly detected and removed the fake Ledge Live app from their store. The company is investigating how the fake Ledger app bypassed its app review process, however, the damage to users is already done.

Remember that apps like Ledger, Trezor, or another hardware wallet will never ask users to enter their recovery phrases into their computers or phones. You should always enter the phrase in the hardware wallet to recover it.

1.  Teen Hacks Ledger Hardware Cryptocurrency Wallet
2.  New DoubleFinger Malware Strikes Cryptocurrency Wallets
3.  All Ledger hardware wallets vulnerable to man in middle attack
4.  Ledger data breach: Hacker leaks stolen database on hacker forum
5.  Crypto wallet Ledger data breach; hackers steal 1m emails, other data

Tag

#microsoft