Keys Findings

Secp0 emerged in early 2025. Initially misunderstood as a group that withholds software vulnerabilities for ransom, it actually operates like a traditional ransomware.
First, it appeared in February 2025, tracked by researchers like PRODAFT. In March 2025, they claimed their first victim, a U.S. IT company, compromising data and encrypting servers.
In May 2025, Secp0 delayed publications, citing a queue of companies and testing a software solution, believed to be the extortion platform World Leaks.
Secp0 is an ELF binary for 64-bit architecture, developed in C/C++, using ChaCha20 encryption and ECDH key exchange.
This report provides a YARA rule for detecting Secp0 based on its embedded encryption key.

Executive Summary

This article analyzes Secp0 ransomware, which emerged in early 2025 and was initially mischaracterized as a vulnerability disclosure extortion group. Our investigation confirms that Secp0 operates as conventional double-extortion ransomware, encrypting data while threatening public disclosure.

A technical analysis reveals an ELF binary targeting Linux systems, implementing ChaCha20 encryption with ECDH key exchange. The malware features configurable command-line options, embedded encrypted data, and an irrecoverable key structure preventing decryption without the attacker's cooperation.

This article provides actionable defenses including YARA detection rules based on hardcoded keys and detailed technical breakdowns.

Introduction to Secp0 Ransomware

In early 2025, a new ransomware group called Secp0 emerged, initially distinguishing itself with a novel extortion model that threatened to undermine conventional vulnerability disclosure practices. PRODAFT mentioned it in a tweet in March. Unlike traditional ransomware actors who encrypt files or leak stolen data, Secp0 allegedly identifies critical software vulnerabilities and demands payment to withhold their public disclosure. However, this understanding of Secp0 turned out to be false. Secp0 operates like many other ransomware groups, employing a double-extortion model where they encrypt victims' data and then threaten to expose it publicly.

Secp0 first appeared on the threat landscape in February 2025. By early March, cybersecurity researchers had begun publicly tracking and documenting the group's activities, with PRODAFT being among the first to alert the security community about Secp0's emergence. At this time, Secp0 had released a blog post about a flaw in Passwordstate, a software for password storage, where they explained it in detail and provided the files of the decompiled software. At that time, their strategy was misunderstood by analysts who thought they had a new extortion model that targeted solutions and then threatened to publicly disclose the vulnerabilities unless a ransom was paid. They made a blog post responding angrily to PRODAFT's tweet.

Also in March 2025, they claimed their first victim publicly, an IT service management company based in the United States. They claimed to have compromised over 900 accounts from the victim's network and encrypted Nutanix servers, Hyper-V servers, and NAS devices with backups. They threatened to publish all data, but until now, only a proof of compromise has been published.

In early May 2025, Secp0 claimed that their publications were on hold because they allegedly had a substantial queue of companies waiting for their data to be published and that their team was actively testing a software solution designed to streamline the publication of large datasets.

We believe that this software solution turned out to be the extortion platform World Leaks (which we discussed in a previous report). We assert with high confidence that the Secp0 ransomware was used on one of the victims claimed by World Leaks.

Technical Analysis

The Secp0 ransomware is identified as an ELF (Executable and Linkable Format) binary, specifically compiled for 64-bit architecture. It is developed using the C/C++ programming languages. Heuristic analysis indicates that the ransomware was compiled using GCC (GNU Compiler Collection) version 12.3.0 or Ubuntu clang version 14.0, on a system running Ubuntu Linux 22.04.

When executing, Secp0 ransomware can take ten arguments in its command line:

--psw [text]
--sleep
--daemon
--nomotd
--path [text]
--novmfs, --nohome, --nostop, --fast and --full: These options were present in the argument parser, but the related codes have not been found.

The ransomware was used like this by the threat actors:

./ran_64.elf --psw secp0 --fast --daemon --path [path]

As is typical with many programs, the execution of the ransomware begins with the main function. This function serves as the primary entry point and orchestrates the subsequent operations by invoking two critical functions: "prepare_encryption" and "recursive_opendir_n_encryption".

int __cdecl main(int argc, const char **argv, const char **envp)
{
    int64 v3; // rdx
    __int64 v4; // rcx
    u32 *v5; // r8
    u32 v6; // er9
    _BYTE main_struct[520]; // [rsp+0h] [rbp-208h] BYREF

    g_argc = argc;
    g_argv = argv;
    init_val_4(main_struct);
    if ( prepare_encryption(main_struct, argv, v3, v4, v5, v6) )
        recursiv_opendir_n_encryption(main_struct);
    cleaning_struct(main_struct);
    return 0;
}

Main Function

The "prepare_encryption" function makes sure that all the encryption requirements are satisfied:

Decrypting the Embedded Ransom Note: This function decrypts the ransom note embedded within the binary, ensuring that it is ready for deployment.
Reading and Verifying Execution Options: It reads and verifies the execution options provided by the user, potentially activating specific functionalities based on these inputs.
Generating Encryption Keys: This function generates the necessary encryption keys and other essential data required for the encryption process.

The "recursive_opendir_n_encryption" function is designed to handle the core encryption operations and has the following primary responsibilities:

Recursive Directory Traversal: It traverses each file and directory recursively, ensuring comprehensive coverage of the target system's file structure.
Writing the Ransom Note: In the case of directories, this function writes the ransom note, making it visible to the user.
File Encryption: It performs the encryption of files, rendering them inaccessible without the appropriate decryption key.

The ransomware binary contains embedded data essential for its operation. These data elements are encrypted to reduce the risk of detection by antivirus software.

The ransomware embeds several critical pieces of information necessary for its execution and functionality:

Ransom Note Template: Template for the ransom note that is displayed to the victim.
File Extension: New file extension (.secp0) assigned to each encrypted file.
Ransom Note Filename: Name of the ransom note file (RESTORE-SERVER.txt).
MOTD File Location: Location of the "message of the day" file (/etc/motd), which displays a message when a user logs in via the command line.
Accepted Arguments: --path, --novmfs, --nohome, --nomotd, --nostop, --psw, --fast, --full, --daemon, --sleep

To decrypt these embedded data, the ransomware employs the ChaCha20 symmetric encryption algorithm. The encryption and decryption keys are hard-coded. The key and initialization vector (IV) used are as follows:

Key : 6162636465666768696A6B6C6D6E6F707172737475767778797A7B7C7D7E7F80
Iv : 0001020304050607

bool __fastcall decrypt_hardcoded_data(int *__shifted(struct_1,8) a1, __int64 a2, __int64 a3, __int64 a4, u32 *a5, u32 a6)
{
    __int64 buffer; // rax
    unsigned __int64 dec_data_1; // rbx
    __int64 dec_data; // rbx
    __int16 *v9; // rax
    __int64 ivbits; // [rsp+8h] [rbp-D0h] BYREF
    __int128 key[2]; // [rsp+10h] [rbp-C8h] BYREF
    chacha_ctx ctx[3]; // [rsp+30h] [rbp-A0h] BYREF

    LODWORD(ADJ(a1)->size_decrypted_data) = 0x1193;
    buffer = __libc_calloc(1uLL, 0x1193uLL, a3, a4, a5, a6);
    ADJ(a1)->dec_data = buffer;
    if ( !buffer )
        return 0;
    dec_data_1 = buffer;
    key[0] = unk_4C2010;
    key[1] = unk_4C2020;
    ivbits = 5060975229142305280LL;
    chacha_keysetup(ctx, key, 32LL, &ivbits);
    chacha_enc(ctx, &encrypted_data, dec_data_1, 0x1193uLL);
    dec_data = ADJ(a1)->dec_data + 0x20;
    v9 = get_struct();
    return chacha_encryption(dec_data, v9);
}

Decrypt hardcoded data

The embedded key can be used to create detection rules for identifying the presence of the ransomware. A YARA rule based on this key is provided at the end of this report, which can be used by security teams to detect and mitigate the threat posed by this ransomware.

Command Line Options Analysis

--psw Option

Description: The --psw option is the first parameter checked by the ransomware.
Functionality: Expects a string that is compared with the first string in the decrypted embedded data within the ransomware.
Purpose:
- Verification of Embedded Data Decryption: Ensures that the decryption process of the embedded data has been successfully completed.
- Safety Mechanism: Acts as a safeguard to prevent the inadvertent execution of the ransomware, ensuring it is only executed intentionally.

__int64 __fastcall prepare_encryption(struct_1 *main_struct, __int64 a2, __int64 a3, __int64 a4, u32 *a5, u32 a6)
{
    __int64 *dec_data_1; // rbx
    __int64 v7; // rax
    __int64 s_psw; // rax
    __int64 s_psw_1; // r12
    __int64 dec_data_2; // rax
    __int128 *decoded_hardcoded_keys; // rax
    __int64 v12; // rcx
    u32 *v13; // r8
    u32 v14; // er9
    __int64 *hc_attacker_pub_key; // r13
    char b_arg_motd; // al
    __int64 ransom_notes; // rbp
    __int64 dec_data; // rax
    __int64 *session_data; // r13
    __int128 *master_shared_key; // rbp
    __int64 hc_dec_data; // rax
    struct_1 *path_etc_motd; // [rsp+8h] [rbp-40h]

    dec_data_1 = &main_struct->dec_data;
    if ( !decrypt_hardcoded_data(&main_struct->dec_data, a2, a3, a4, a5, a6) )
        goto LABEL_14;
    v7 = deref_a1(dec_data_1);
    if ( !set_struct(&main_struct->s_args_path, v7) )
        goto LABEL_14;
    if ( !read_n_set_params(&main_struct->s_args_path, g_argc, g_argv) )
        goto LABEL_14;
    s_psw = deref_psw(&main_struct->s_args_path);
    if ( !s_psw )
        goto LABEL_14;
    s_psw_1 = s_psw;
    dec_data_2 = deref_a1(dec_data_1);
    if ( j_strcmp_ifunc(s_psw_1, dec_data_2) )    // check passwd, option ---psw
        goto LABEL_14;

    // ... 
}

Option --psw

--sleep Option

Description: The --sleep option pauses the program execution.
Functionality: Introduces a delay of 60 seconds (0x3C in hexadecimal).
Purpose:
- Delay Execution: Helps in evading detection by delaying the onset of noticeable system changes, potentially allowing the ransomware to run further before being detected.

if ( deref_offset_a1_0(&main_struct->s_args_path) )  // arg sleep
    to_clock_nanosleep_0(0x3Cu);

Call to function "to_clock_nanosleep_0" with argument 0x3C

__int64 __fastcall to_clock_nanosleep_0(unsigned int a1)
{
    unsigned int v1; // ebp
    int v2; // ecx
    int v3; // er8
    int v4; // er9
    __int64 result; // rax
    __int64 v6; // rdx
    __int64 v7[3]; // [rsp+0h] [rbp-30h] BYREF
    unsigned __int64 v8; // [rsp+18h] [rbp-20h]

    v8 = __readfsqword(0x28u);
    v1 = __readfsdword(0xFFFFFB8);
    v7[0] = a1;
    v7[1] = 0LL;
    if ( to_clock_nanosleep(v7, v7) < 0 )
        // ...
}

Call to function "to_clock_nanosleep"

__int64 __fastcall to_clock_nanosleep(__int64 a1, __int64 a2)
{
    __int64 result; // rax

    result = clock_nanosleep(0LL, 0LL, a1, a2);
    // ...
}

Call to function "libc clock_nanosleep"

--daemon Option

Description: The --daemon option restarts the program as a background process.
Functionality: Redirects the output to a log file named log.secp0.
Purpose:
- Stealth Operation: Increases the ransomware stealth by running it in the background, making it harder to detect and terminate as it does not require an active user session.

if ( deref_offset_a1(&main_struct->s_args_path) )  // arg daemon
    daemon_mode_fork(main_struct, session_data);

Call to function "daemon_mode_fork"

__int64 __fastcall to_fork_setsid_n_dup2(struct_1 *a1, __int64 a2)
{
    int v2; // eax
    unsigned int v3; // ebx
    __int64 v4; // rax
    unsigned int fd; // eax
    unsigned int fd_1; // ebp
    unsigned int v7; // eax
    unsigned int v8; // eax
    int v10; // eax
    int v11; // edx
    int v12; // ecx
    int v13; // er8
    int v14; // er9
    char v15; // [rsp+0h] [rbp-18h]

    v2 = __libc_fork(a1, a2);
    if ( v2 == -1 )
        return 0;
    if ( v2 > 0 )                                    // success
    {
        v10 = deref_a1(&a1->dec_data);
        _printf(v10 + 321, a2, v11, v12, v13, v14);
        goto LABEL_12;
    }
    if ( to_setsid() == -1 )                         // create new session and process group
        return -1;
    v3 = __libc_fork(a1, a2);
    if ( v3 != -1 )
    {
        if ( !v3 )
        {
            v4 = deref_a1(&a1->dec_data);
            fd = __libc_open64(v4 + 0x171, 0x42, v15);  // create file log.scp0 (RDWR)
            v3 = 1;
            if ( fd != -1 )
            {
                fd_1 = fd;
                v7 = sub_43E000(off_4FB970);            // redirect stdout / stderr
                to_dup2(fd_1, v7);
                v8 = sub_43E000(off_4FB968);
                to_dup2(fd_1, v8);
            }
        }
        return v3;
    }
LABEL_12:
    to_exit(0);
    return v3;
}

Fork of the process and redirection of stdout and stderr in a file

--nomotd Option

Description: The --nomotd option prevents the automatic modification of the system welcome message.
Functionality: Ensures that the Message of the Day (MOTD) file is not altered when a user logs in via the command line.
Purpose:
- Avoid Detection: Prevents immediate notification to users about the ransomware infection through the MOTD, which could otherwise serve as an early warning mechanism.

--path Option

Description: The --path option is a mandatory parameter.
Functionality: Specifies the directory to be encrypted.
Purpose:
- Target Specification: Allows the attacker to target specific directories, making the ransomware more flexible and targeted in its operations.

char __fastcall recursiv_opendir_n_encryption(struct_1 *a1)
{
    __int64 arg_path; // rax
    __int64 arg_dir_1; // r14
    __int64 v3; // rax
    __int64 v4; // rax

    arg_path = to_deref_a1(&a1->s_args_path);
    if ( arg_path )
    {
        arg_dir_1 = arg_path;
        v3 = to_deref_a1_0(&a1->struct_buffer_file_enc);
        strcpy(arg_dir_1 + 0x48, arg_dir_1);
        v4 = to_deref_a1_0(&a1->struct_buffer_file_enc);
        to_encrypt_files(&a1->ransom_notes, v4 + 72, 1024uLL);
        return 1;
    }
    return 0;
}

Option --path

Other Options

Description: Additional options include --novmfs, --nohome, --nostop, --fast, and --full.
Usage: No evidence of usage for these options was found during the analysis.
Purpose:
- Flexibility and Control: While these options are present in the argument parser, their specific functionalities and impacts remain undetermined because the related code is missing.

Encryption Process Explanation

The encryption process of the ransomware is initiated when the user specifies a directory using the --path option. The contents of this directory are listed, and each file, except for the ransom note "RESTORE-SERVER.txt", is sent as an argument to the encryption function. If a directory is encountered, the function recursively lists and encrypts its contents.

v17 = get_directory_entries(v5, s_path, v6, v7, v8, v9);
if ( v17 )
{
    v18 = v17;
    struct_stat64 = &ADJ(v4)->field_140;
    do
    {
        v25 = (v18 + 19);
        v26 = ".";
        if ( j_strcmp_ifunc(v25, ".") )
        {
            v20 = "..";
            if ( j_strcmp_ifunc(v25, "..") )
            {
                *v10 = 47;
                j_strcat_ifunc(s_file_path, v25);
                v26 = &ADJ(v27)->field_140;
                if ( !__xstat64(s_file_path, struct_stat64) )
                {
                    if ( (ADJ(v27)->field_158 & 0xF000) == S_IFDIR )
                    {
                        v20 = s_file_path;
                        list_files_recursively_n_call_encryption(v27, s_file_path, maybe_size);
                    }
                    else
                    {
                        v26 = (ADJ(v27)->dec_data_ + 96);
                        if ( j_strcmp_ifunc(v25, v26) )  // compare str to RESTORE-SERVER.txt
                        {
                            v20 = &ADJ(v27)->field_140;
                            ADJ(v27)->s_encrypt_files(s_file_path, struct_stat64, ADJ(v27)->main_struct);
                        }
                    }
                }
                *v10 = 0;
            }
        }
        v18 = get_directory_entries(v5, v20, v21, v22, v23, v24);
    }
    while ( v18 );
}
to_free_n_close(v5);

Call of the encryption function to encrypt the files present in the directory

At the beginning of this process, the ransom note "RESTORE-SERVER.txt" is created in each directory.

bool __fastcall write_ransom_notes(__int64 *__shifted(struct_1,0x120) struct_offset, __int64 s_path, __int64 maybe_size)
{
    __int64 s_file_path; // r15
    __int64 *__shifted(struct_1,0x120) v4; // rbp
    unsigned int *v5; // rbx
    __int64 v6; // rax
    __int64 v7; // rcx
    u32 *v8; // r8
    u32 v9; // er9
    _WORD *v10; // r13
    __int64 v11; // rax
    int *v12; // rbp
    __int64 v13; // rdx
    __int64 v14; // rcx
    u32 *v15; // r8
    u32 v16; // er9
    char *v17; // rax
    char *v18; // r12
    __int64 *struct_stat64; // rbp
    char *v20; // r11
    __int64 v21; // rax
    __int64 v22; // rcx
    __int64 v23; // rdx
    u32 v24; // er9
    __int64 v25; // r12
    __int64 *__shifted(struct_1,0x120) v27; // [rsp+0h] [rbp-40h]

    s_file_path = s_path;
    v4 = struct_offset;
    v5 = opendir(s_path);
    if ( v5 )
    {
        v10 = (s_path + j_strlen_ifunc(s_path));
        if ( ADJ(struct_offset)->ransom_notes && ADJ(struct_offset)->dec_data_ )
        {
            *v10 = 47;
            j_strcat_ifunc(v10, ADJ(struct_offset)->dec_data_ + 96);  // build ransom notes path /dir/RESTORE-SERVER.txt
            v11 = to_new_fopen(s_file_path, "w0");
            if ( v11 )
            {
                v12 = v11;
                s_path = 1LL;
                io_fwrite(*ADJ(struct_offset)->ransom_notes, 1LL, *ADJ(struct_offset)->ransom_notes + 8), v11);
                io_new_fclose(v11, 1LL, v13, v14, v15, v16);
            }
        }
        *v10 = 0;
        v5 = struct_offset;
    }
    return v5;
}

Creation of the ransom note RESTORE-SERVER.txt

The ransomware employs the ChaCha20 symmetric encryption algorithm for encrypting files. This means the same key is used for both encryption and decryption. The key is generated using the Elliptic Curve Diffie-Hellman (ECDH) key exchange protocol, specifically utilizing the secp256k1 elliptic curve. This protocol securely exchanges a shared key using a public-private key system.

1 - Session Key Pair Generation:

When the ransomware is executed, a pair of public and private keys, known as session keys is generated.

2 - File Key Pair Generation:

For each file to be encrypted, another pair of public and private keys, known as file keys, is generated.

3 - Shared Key Calculation:

The encryption key is derived as a shared key calculated from the session public key and the file private key. This shared key can also be calculated by combining the session private key and the file public key.

Before encrypting a file, the ransomware appends necessary information for decryption at the end of the file.

__int64 __fastcall append_to_file_deckey(__int64 fd, stat64 *stats, struc_2 *struct_enc, __int64 a4, u32 *a5, u32 a6)
{
    __int64 v6; // rax
    __int64 tmp_pub_file_key; // rax
    __int64 tmp_pub_file_key_1; // rbp
    __int64 len; // r12
    int v11[3]; // [rsp+0h] [rbp-20h] BYREF

    v6 = a4;
    if ( a4 )
    {
        tmp_pub_private_shared_key_setchacha(struct_enc->ptr_info_decrypt_file, struct_enc, a4LL, a4, a5, a6);  // generate file public/private key
                                                                                                                // create shared secret using public session key and private file key
        v11[0] = 0;
        tmp_pub_file_key = get_tmp_priv_pub_key(struct_enc->ptr_info_decrypt_file, v11);
        if ( tmp_pub_file_key )
        {
            tmp_pub_file_key_1 = tmp_pub_file_key;
            len = get_struct();
            memcpy(struct_enc->file_pubkey, len);
            *a4 = struct_enc->file_size = 0;
            if ( struct_enc->dec_option == 1 )
            {
                if ( 0x6000000 )
                {
                    if ( struct_enc->file_size < 0x6000000ULL )
                    {
                        *a4 = 0;
                        struct_enc->file_size = v11;
                    }
                }
            }
            if ( __fseek64(fd, 0LL, SEEK_END) && to_fwrite(struct_enc->file_pubkey, 1LL, 0x80ULL, fd) == 0x80 )  // append to file keys needed to decrypt
                v6 = __fseek64(fd, 0LL, SEEK_SET) != 0;
        }
        else
        {
            v6 = 2;
        }
    }
    return v6;
}

Adding to the end of the file to be encrypted the information necessary for decryption

The appended data (177 bytes) includes:

File Public Key: The public key specific to the file.
Attacker Public Key: The attacker's public key, embedded within the ransomware.
Encrypted Session Private Key: The session private key, which is encrypted.
Session Public Key: The public key of the session.
Temporary Public Key: A temporary public key.
Random Value: A random value that appears to be unused.

    0x00000000 sigfile struct ; (sizeof=0x81, mapped to 48)
    0x00000000 compression_type_0 db ?
    0x00000001 file_pubkey        db 32 dup(?)
    0x00000021 compression_type_1 db ?
    0x00000022 hc_attacker_pub_key db 32 dup(?)        ; string(C)
    0x00000042 session_private_key db 32 dup(?)
    0x00000062 compression_type_2 db ?
    0x00000063 tmp_public_key     db 32 dup(?)
    0x00000083 compression_type_3 db ?
    0x00000084 session_public_key db 32 dup(?)
    0x000000A4 field_A4          db ?
    0x000000A5 field_A5          db ?
    0x000000A6 field_A6          db ?
    0x000000A7 field_A7          db ?
    0x000000A8 maybe_rande_type  db ?
    0x000000A9 rand              dq ?
    0x000000B1 sigfile           ends

Structure of added data

The session private key, crucial for decryption when combined with the file public key, is encrypted. However, the file "private key" is missing, which means the file cannot be decrypted using only the appended information. The session private key is encrypted using the ChaCha20 algorithm, with the encryption key derived from a combination of the attacker's public key and a temporary private key generated by the ransomware. Since both the temporary private key and the attacker's private key are unknown, it is impossible to recreate the encryption key.

Here is an explanation of the encryption process of Secp0 ransomware:

IoCs

Indicators	Indicator type	Description
bbcf4469a0a849ec3c65bbf2ad188896f8d222b7f4e6e5b1c85747ae3ad95818	sha256	Secp0 ransomware binary
secp0-support[.]net	domain name	Secp0 Negociation Pannel
secp0-support[.]cfd	domain name	Secp0 Negociation Pannel
bhn2xz5jer2xeibxjzhgfp7qclttnbvkkvd4hvlmjbnz66jxq7yzn6ad[.]onion	onion address	Secp0 Negociation Pannel
2a6w667vebiebciji7vm3vj43svegvozoqypttdgojzgdcbnfsu5wiid[.]onion	onion address	Secp0 Negociation Pannel
secponewsxgrlnirowclps2kllzaotaf5w2bsvktdnz4qhjr2jnwvvyd[.]onion	onion address	Secp0 Blog

YARA Rule

rule secp0 {
    meta:
        title = "SECP0 ransomware detection"
        description = "match embedded ransomware note decryption key"
        date = "2025-06-30"
        author = "Lexfo"
        os = "Linux, maybe Windows"
        score = 90
    strings:
        $key = { 6162636465666768696A6B6C6D6E6F707172737475767778797A7B7C7D7E7F80 }
        $iv = { 0001020304050607 }
        $chacha1 = "expand 16-byte k"
        $chacha2 = "expand 32-byte k"
    condition:
        all of them
}

Ransom Note

======================================
What happened?
======================================

Greetings, [Victim].
Your network has been fully compromised, investigated, and over [Size] of data including the contents of your file servers and database dumps has been extracted. [Explanations]

If you fail to contact us, we will begin publishing this data on our blog and alerting relevant government authorities. A breach of this scale could result in lawsuits, substantial fines, and irreparable reputational damage. Consider how investors and stakeholders will react if this incident goes public.

Additionally, the data stores of your hosts have been encrypted using modern cryptographic algorithms. However, we are prepared to provide you with a decryption tool.

======================================
How to obtain the decryption tool?
======================================

To obtain the decryption tool and ensure the deletion of your data from our servers, you must make a payment. If you fail to contact us within three days or refuse to pay, we will have no choice but to begin publishing your data on our blog and notify all relevant parties, including your investors.

======================================
What should you do next?
======================================

Next, you need to contact us by following the links in the next section and discuss with us the terms for deleting data on our side and obtaining a decryption key for your servers that will satisfy both us and you.

Additionally, to confirm our words, we are ready to:

- provide you with a partial listing of the files that were uploaded (partial means no more 
than 33% of the entire tree)

- provide you with several ANY files (up to 10MB each) from the provided file listing

======================================
How to contact us?
======================================

To get in touch with us, you can use the links below.

- https://secp0-support.net/xxxxxx

- https://secp0-support.cfd/xxxxxx

- http://bhn2xz5jer2xeibxjzhgfp7qclttnbvkkvd4hvlmjbnz66jxq7yzn6ad.onion/xxxxx

- http://2a6w667vebiebciji7vm3vj43svegvozoqypttdgojzgdcbnfsu5wiid.onion/xxxxx

To access the onion link, you'll need to download and install the Tor Browser 
(https://www.torproject.org/download).

======================================
What guarantees are there?
======================================

As a guarantee, we can offer you our professionalism. We have breached your network, extracted data from it, and remained within it for months. Our business is built on keeping our promises. Otherwise, no one would work with us or pay us. Reputation drives payments.

To confirm that we were in your filestorages, servers, and your endpoints, you can view the listing and request any file from it as proof. Additionally, as a bonus, after payment, you will receive a detailed report on your network's security: how to improve it, how to prevent future breaches, what mistakes were made, and how to avoid such situations in the future. Similar reports cost hundreds of thousands when done by professional Red Teams. We are better than a Red Team — we are the ones security companies promise to protect you from. Our reports are even more valuable. And they come as a bonus with your payment, free of charge.

[Explanation]

---BELOW IS TECHNICAL INFORMATION REQUIRED FOR US TO PROVIDE YOU WITH DECRYPTION TOOL, DO NOT REDACT---
ID=[ID]
---FINISH---