From a Pension-Themed Spear-Phishing Email to a GitHub-Backed Implant: Investigating a SideWinder Connection

The story in five minutes

It looked like an ordinary administrative email: a notice about changes to pension rules, apparently sent from a trusted government address. The attachment was locked with a password, and the password—0035—was helpfully written in the message. Recipients were asked to open the document and confirm that they had received it.

That small act of helpfulness was part of the trap.

The attachment was not simply a document. Hidden inside it was a compressed archive, encoded as more than half a million decimal characters. When reconstructed, the archive revealed a Windows program named DellHeuristics.exe. The document also contained a chain of scripts designed to unpack the program, place it in a user-writable directory, arrange for it to run again, and contact internet services.

The program did not depend on an obviously named criminal server in the observed execution path. It used familiar public services—including GitHub—in a sequence that could blend into normal web traffic. In the laboratory, it asked for public-network information, downloaded a small bootstrap value, read a GitHub repository marker, obtained credential-shaped material in memory, and constructed authenticated GitHub API check-in traffic.

The investigation then moved beyond the file. One IP address embedded in the program, 88.119.161[.]40, had already been published by Bangladesh e-GOV CIRT in August 2025 as an indicator connected to a government-targeting phishing campaign. The email examined here was dated about 40 days later. Subsequent reporting on Operation SouthNet and SideWinder described similar regional targeting, government-themed lures, and abuse of trusted online infrastructure across South Asia, including Myanmar.

That creates a serious connection worth investigating—but not a complete attribution. The evidence confirms the malicious email-to-implant chain, active network behavior in the lab, and an exact overlap with a previously published campaign indicator. It does not yet prove who sat behind the keyboard.

The short version: a targeted pension-themed email concealed an embedded implant. The implant actively used GitHub-backed infrastructure, and one of its network indicators overlaps exactly with earlier regional phishing reporting. SideWinder is a credible lead, not yet a proven verdict.

The investigation question

The question was not simply, “What does this executable do?” It was:

How did a trust-themed email become a persistent implant, where did the implant communicate, and what can public threat intelligence responsibly tell us about the campaign behind it?

Answering that question required four evidence layers:

• the original email and its delivery pretext;
• the password-protected Word attachment and its embedded content;
• the recovered executable, scripts, and intended host artifacts; and
• runtime debugger and memory evidence showing which network paths were actually reached.

The investigation then pivoted from locally recovered IOCs into public reporting. That final step is where correlation can easily become over-attribution, so confirmed facts, contextual similarities, and unresolved claims are separated throughout this article.

A quick reader's guide

No specialist knowledge is required to follow the investigation. These terms appear throughout the article:

Readers interested mainly in the attack story can follow the stage headings and bold conclusions. The tables, hashes, API paths, and ATT&CK mappings preserve the details needed by defenders and researchers.

Laboratory methodology and scope

The investigation used two deliberately separate paths. The document-analysis path preserved the original EML, decrypted the attachment offline with the supplied password, examined the OOXML/VBA and UserForm content, reconstructed the embedded ZIP, and identified the executable and staged scripts. The runtime path started the extracted DellHeuristics.exe directly under x64dbg. It did not dynamically replay the complete WINWORD.EXE-to-payload chain. Two executable instances were examined: PID 452 supplied the original request and memory sequence, while PID 1608 supplied a second, more tightly instrumented run.

This scope distinction matters. Static evidence can establish what the document and executable were built to attempt. Runtime evidence can establish what the directly launched executable reached in this laboratory run. Neither, by itself, proves that an original recipient enabled the document, that persistence completed on a victim endpoint, or that a remote service accepted every request.

How claims are classified

Evidence and privacy boundary

The analysis was performed in an isolated, authorized Windows laboratory. The retained case material included the original EML, the extracted Word document, the recovered executable, x64dbg screenshots, six Full User-Mode Dumps from two process instances, and corresponding MalwareINFO Payload & Memory Analyzer packages.

The public article does not expose recipient names, the complete recipient list, the apparent sender's personal identity, raw identifying email content, a recovered GitHub credential, reversible bootstrap secrets, raw process dumps, or screenshots containing memory-resident secrets.

An address in a From header is not proof that the named person or organization sent the message. Compromised accounts, spoofing, forwarding infrastructure, and manipulated headers are all possible. The apparent sender is therefore treated as part of the lure, not identified as the attacker.

Stage 1: the message was designed to feel routine

The spear-phishing message was dated 15 September 2025. Its subject and body presented the attachment as a change to pension-related rules. Several choices increased the likelihood of engagement:

• the message appeared to originate inside a trusted government-mail context;
• the subject concerned an administrative matter relevant to public-sector recipients;
• the attachment password was supplied in the message, making encryption feel procedural rather than suspicious; and
• the request to acknowledge receipt added urgency and social pressure.

What the recipient would have seen

Opening the attachment with the supplied password would not immediately present the recipient with a command window, an unfamiliar program, or a page announcing that malware was running. The visible document content preserved in the OOXML package presented pension and e-Pension material in the style of a government office letter. It used an official-looking layout, seals or emblems, and government-department imagery to support that appearance.

To the recipient, this did not look like opening malware. It looked like opening a work-related government circular about pension rules—the kind of document an employee might reasonably be expected to read, check, or acknowledge.

That distinction is central to the attack. The visible letter was not merely decoration placed around the malware. It was the social-engineering layer that explained why the file had arrived, why it was password-protected, and why the recipient should spend time reading it. While attention remained on the familiar office document, the hidden macro and embedded data supplied the technical path toward the implant.

Depending on the version of Microsoft Office and the organization's security policy, a recipient might also encounter Protected View, an external-content notice, or a prompt related to active content. Such a prompt would be the security boundary between viewing the lure and allowing part of its hidden functionality to proceed; the exact prompt shown on any original recipient endpoint was not preserved in the available evidence.

The original letter is not reproduced here. Names, departmental identifiers, recipient information, signatures, seals, and other identifying details remain withheld. The investigation also does not certify that the visible policy text, branding, or signatures were genuine. They are treated as lure material copied, adapted, or assembled to create trust.

Why an employee might open it: the topic was relevant to government work, the layout resembled official correspondence, the sender appeared familiar, the password suggested confidentiality, and the message requested acknowledgement. Each detail reduced suspicion while increasing the pressure to act.

This was not a broad consumer scam. The 48 address entries and the government-specific pretext indicate a selected institutional audience. However, the EML alone cannot establish which recipients received, opened, or executed the attachment.

Password protection served two purposes. Socially, it made the file appear confidential. Technically, it reduced the visibility of the attachment to some email scanners that could not inspect the encrypted content without the password.

In other words, the same feature that made the document appear more official also helped hide it from automated inspection.

Stage 2: the “document” carried a program inside it

The attachment was named dop0035-2025.doc. Its SHA-256 digital fingerprint was:

EADD9F97166B59A02D9C25CD2FF721ED06B7C28050AA08DB3FE80B97ACBB80BA

After controlled offline decryption with password 0035, the internal structure showed that this was a macro-enabled OOXML document. Put simply, its .doc name did not accurately describe what was inside, and the file was capable of running embedded instructions.

The macro project contained a 507,077-character sequence of decimal numbers. It was a way of hiding a file in plain sight: each group represented a byte. Converting the numbers back into bytes produced 50 4B 03 04, the standard opening signature of a ZIP archive. The complete reconstruction yielded a 141,491-byte ZIP containing one file:

This establishes the direct lineage from the malicious document to the executable. The primary payload was embedded in the attachment; it did not need to be downloaded from the later callback infrastructure.

Stage 3: the implant was prepared to survive

The document's VBA and staged scripts described an intended host sequence:

Password-protected email attachment
        ↓
Document_Open macro path
        ↓
Decimal bytes reconstructed as DellHeuristics.zip
        ↓
VBS and BAT launch chain
        ↓
Shell.Application Namespace.CopyHere extraction
        ↓
%LOCALAPPDATA%\DellHeuristics.exe
        ↓
Startup-folder script + DellHeuristicsUpdate scheduled task

Recovered strings and code referenced %LOCALAPPDATA%\Microsoft\DellHeuristics.zip, %LOCALAPPDATA%\DellHeuristics.exe, several staged VBS/BAT files, a VBS launcher in the current user's Startup folder, and a scheduled task named DellHeuristicsUpdate configured on a five-minute interval.

For a non-technical reader, the purpose is straightforward: place the implant where a normal user account can write files, then create more than one opportunity for it to start again. The Startup-folder script would be relevant at logon; the scheduled task was intended to provide a repeating five-minute trigger.

These findings establish intended deployment and persistence logic. They do not prove that every step completed on a victim endpoint. Macro policy, Mark-of-the-Web behavior, script-host controls, asynchronous ZIP extraction, and a later logon requirement could all affect execution. The chain should therefore be described as source-reconstructed intent unless endpoint telemetry confirms the artifacts.

Two chains, two evidence levels

• Document-derived intended chain: email attachment → Office macro → reconstructed ZIP → VBS/BAT staging → executable placement → persistence attempts.
• Runtime-confirmed scope: the already extracted DellHeuristics.exe → WinHTTP request sequence → response bytes and changing memory state.

The second chain corroborates malicious capability inside the recovered payload. It must not be presented as a dynamic replay proving that the first chain completed on an original recipient's computer.

Stage 4: legitimate internet services became camouflage

Lookalike document infrastructure

The document referenced edmsvpn.gov.en-mm[.]com for an external image and a macro callback. The registrable domain is en-mm.com, not a Myanmar government domain. The embedded gov label is a deceptive subdomain component designed to resemble official infrastructure.

Fallback network IOC

The executable contained 88.119.161[.]40. This address became the strongest public-intelligence pivot because it independently appeared in the Bangladesh e-GOV CIRT phishing advisory published before the observed email.

GitHub-backed bootstrap and remote control/check-in channel

GitHub is normally a software-development service. That reputation and widespread business use can make GitHub traffic less conspicuous than a connection to an unknown server. Here, the service was used as part of a staged workflow: one location supplied a small bootstrap value, another supplied operational data, and a later request attempted to write content.

Runtime analysis showed the process using legitimate public services in an application-specific sequence. The table distinguishes the original PID 452 sequence from the later PID 1608 AnalystModified sequence, and it keeps an API-entry observation separate from a returned response and a verified remote effect.

Request-handle context was visible in registers and stack frames during debugging, but the retained notes did not normalize a stable hRequest value for every row. The table therefore does not invent one. In evidentiary terms, API observed ≠ HTTP success ≠ remote effect.

The raw GitHub object returned 64 Base64 characters plus a newline. Offline analysis showed that the material participated in recovering a token-shaped GitHub credential, but the credential and reversible secret chain are intentionally withheld.

The GitHub API GET returned the exact 11 bytes Readme9823\n. The caller found Readme9823 at offset zero and followed its continuation branch, supporting its role as a remote enable marker. In PID 452, the later PUT reached WinHttpSendRequest and WinHttpReceiveResponse, but no HTTP status, response body, Git object, or independently verified repository change was retained. This supports an attempted GitHub Contents API write, not a proven successful upload or exfiltration event.

What was in the PUT body—and what the evidence proves

The more tightly instrumented PID 1608 run resolved this question. Its PUT body was exactly 33 bytes: {"message": "add", "content": ""}. No sha or branch field was present, and content was an empty string. The most conservative interpretation is an attempt to create an empty repository object as a check-in marker—not exfiltration of document content, host inventory, or command output.

The PID 1608 send was intentionally stopped and synthetically bypassed before WinHttpSendRequest executed. The follow-up GET was also bypassed. Those controls prevented a new remote mutation during the confirmatory run, but they also mean that this run supplies request-construction evidence only. It cannot establish server acceptance or intended post-PUT state.

A Myanmar-only gate explained the early exits

The PID 1608 run retained the ip-api[.]com JSON response. It reported Malaysia and countryCode MY, consistent with the laboratory VPN exit. Disassembly then exposed a country gate equivalent to countryCode == "MM". With the original MM literal intact, the comparison failed and the program called ExitProcess(1).

To examine the code beyond that boundary, the analyst changed the in-memory literal from MM to MY. That edit did not reveal a naturally satisfied environment check; it deliberately made the laboratory response pass. Every subsequent PID 1608 observation is therefore classified AnalystModified. The original code still supports a clear conclusion: this execution branch was designed to continue only when the external geolocation response identified Myanmar.

Stage 5: six memory snapshots across two instances showed the workflow evolving

The first three complete process dumps came from the same DellHeuristics.exe instance, bound by PID 452, process creation time 639246080466940341 UTC ticks, x64 architecture, image identity, and executable SHA-256 CBBE346B679871B3A70B0493DC52565280211B3354F480DC0C02ABCFB862AF87.

All three manifests classify the artifacts as completed FullUserModeDump captures with complete coverage and the diagnostic MiniDumpWriteSucceeded. Collection used the x64 dbghelp.dll file version 10.0.26100.8328, SHA-256 1463249A85BB239FCB536780F3B964C5F2FD68398FFBD35EBEC0D65660C8D83E.

The comparison combined targeted raw-byte/ASCII searches for the known, redacted sequence with MalwareINFO's normalized process-memory string extraction. The analyzer recorded ASCII and UTF-16LE strings with offsets and region-streaming provenance. The public notes do not preserve a normalized virtual address, memory protection, and region identifier for every credential match, so those details are not reconstructed after the fact.

Think of the three dumps as photographs of the same room taken at different times. The searched byte sequence was not identified within the defined search scope of the earlier snapshot, but it was present in the next two. That change supports the assessment that the program acquired or created the value while it was running. The debugger sequence—raw-object retrieval followed by authenticated GitHub API activity—provides the surrounding runtime context.

The second set of three dumps belongs to PID 1608, process creation time 639246397685975969 UTC ticks, and the same executable SHA-256. Their manifest hashes were independently recomputed and matched.

All three PID 1608 manifests report completed FullUserModeDump collection with Complete coverage and MiniDumpWriteSucceeded. A bounded scan of private memory in the final capture found the known ip-api[.]com, raw.githubusercontent[.]com, and api.github[.]com artifacts and their paths. Within this execution stage, no separate dedicated C2 was observed before termination. That result does not prove that no conditional or encoded endpoint exists; it only states what this run and these captures exposed.

The earlier fifth-request gap is now closed: it was the same-path verification GET that followed construction of the randomized .txt PUT. Because both calls were synthetically bypassed in PID 1608, neither remote acceptance nor the intended verification result was observed.

Following one IP address into a wider campaign

The Bangladesh e-GOV CIRT report *Phishing Campaign on Cyber Space of Bangladesh*, dated 6 August 2025, described a targeted campaign that originated from compromised government and law-enforcement email accounts, relied on institutional trust, targeted public-sector recipients, and used password-protected malicious Word documents. Its published IOC list includes 88.119.161[.]40—the same IP recovered from the executable in this case.

This is a confirmed intelligence overlap. It is like finding the same unusual telephone number in two separate investigations: much more useful than merely observing that both callers used a similar story. The value is exact, and the public report predates the 15 September email by approximately 40 days. It supports a working hypothesis that the Myanmar case intersected with infrastructure already associated with regional government-targeting phishing activity.

It still does not prove common operators. An IP can be reused, shared, reassigned, proxied, or incorporated into unrelated tooling. Strong attribution requires additional overlap such as matching malware lineage, unique protocol behavior, domains, certificates, registration patterns, code, build artifacts, or operator-controlled accounts.

Why SideWinder enters the story

The SideWinder hypothesis emerged because the IOC pivot sits inside a broader body of reporting about sustained government-focused phishing across South Asia.

Hunt.io's *Operation SouthNet*, published on 1 October 2025, attributed a regional cluster to SideWinder and documented phishing and malware activity across Bangladesh, Nepal, Myanmar, Pakistan, and Sri Lanka; government, defense, maritime, and critical-sector targeting; political and administrative lure documents; abuse of trusted public infrastructure; and Myanmar credential phishing tied through infrastructure pivots to legacy SideWinder assets.

Why the 2026 Bangladesh e-GOV CIRT report matters

The Bangladesh e-GOV CIRT advisory *SideWinder Spear-Phishing Campaign Against Bangladesh Leveraging Dual-Format Weaponized Documents*, published on 30 July 2026, is more than a passing reference. It provides the retrospective bridge between the 2025 phishing evidence and the SideWinder hypothesis.

The advisory describes activity between 21 April and 28 July 2026 involving 11 parent domains and more than 60 impersonation subdomains. It assesses sustained targeting of government, defence, and diplomatic organizations across Bangladesh, Sri Lanka, Nepal, and Pakistan, while also connecting the activity to earlier 2024–2025 operations and Hunt.io's Operation SouthNet.

Three details are especially relevant to this case:

1. Administrative lures were part of the targeting model. The advisory identifies HR, pay-scale, allowance, promotion, training, diplomatic, and defence themes. A pension-rules notice belongs to the same broad class of government administrative lure.
2. Document format was deliberately used as a trust and delivery mechanism. The reported campaign used active DOCX and PDF files, remote template injection, victim tracking, and a CVE-2017-0199 delivery kit. It also documented clean and weaponized versions of similarly titled documents circulating as cover.
3. The campaign evolved across multiple delivery kits. The report does not describe one immutable malware chain. It describes recurring targeting and infrastructure patterns while delivery methods changed over time.

This strengthens the case for comparison, but it also exposes an important difference. The pension-themed attachment analyzed here contained an embedded executable reconstructed from decimal data and used a macro/VBS/BAT chain. The 2026 advisory's principal kits used remote-template and OLE exploitation paths. Shared audience, lure style, region, and earlier IOC context are meaningful; different payload construction prevents us from declaring the two artifacts part of the same operation without additional evidence.

The one-year analysis gap changes what can still be observed

The email is dated September 2025, while the full laboratory investigation was performed in September 2026. That delay matters operationally.

By the time a year-old implant is executed in a lab, an attacker may have deleted a repository object, revoked a token, abandoned a domain, changed DNS, shut down an IP service, replaced tasking content, or introduced environment checks. A failed callback in 2026 therefore does not prove that the infrastructure was unavailable when the email was sent in 2025. Equally, a service that still responds in 2026 does not prove that it served the same content a year earlier.

The most reliable historical reconstruction must combine the retained sample with time-appropriate DNS, passive DNS, certificate history, proxy logs, email-gateway records, GitHub audit evidence, and archived threat intelligence. This is infrastructure decay, not evidence that the malware “did nothing.”

What connects this case to the reporting

The responsible statement is not “SideWinder confirmed.” It is: the case shares a pre-existing IOC with a Bangladesh government phishing report and fits parts of the regional SideWinder playbook. That relationship warrants further intelligence collection, but the available evidence does not close the attribution gap.

End-to-end attack narrative

1. Initial access attempt: selected recipients received a pension-themed message that appeared to come from a trusted government-mail context.
2. Defense evasion: the attachment was password-protected, with the password delivered in the email.
3. User execution dependency: the recipient had to open the attachment and permit active document content to run.
4. Embedded payload recovery: VBA reconstructed a ZIP archive containing DellHeuristics.exe.
5. Persistence intent: staged VBS/BAT logic targeted the Startup folder and a five-minute scheduled task.
6. Network discovery: the executable queried ip-api[.]com for public-network context.
7. Country gate: the original code required the geolocation response to identify Myanmar before continuing; the confirmatory run proceeded only after an analyst patch and is labeled AnalystModified.
8. Bootstrap: it retrieved a small value from raw.githubusercontent[.]com and later held credential material in memory.
9. Remote workflow: it read a GitHub repository marker, constructed an authenticated empty-file PUT, and prepared a same-path verification GET.
10. Campaign pivot: the fallback IP matched an IOC published by Bangladesh e-GOV CIRT before the email was sent.
11. Attribution assessment: SideWinder reporting provides a credible regional and tactical hypothesis, but direct operator attribution remains unresolved.

ATT&CK-oriented interpretation

ATT&CK mappings describe behavior, not actor identity. Their evidence level is retained here to prevent code-derived capability from being mistaken for victim-side execution.

Indicators and hunting leads

Treat these values as investigation pivots, not automatic proof of compromise.

File hashes

• SpearPhising.eml — 61D2FB525DA40827D54066AEDCEB0489DC44AEF694CA925A1B120D0A9CF4DC65
• dop0035-2025.doc — EADD9F97166B59A02D9C25CD2FF721ED06B7C28050AA08DB3FE80B97ACBB80BA
• DellHeuristics.exe — CBBE346B679871B3A70B0493DC52565280211B3354F480DC0C02ABCFB862AF87

Network indicators

• 88.119.161[.]40
• edmsvpn.gov.en-mm[.]com
• ip-api[.]com
• raw.githubusercontent[.]com/drivelogo1/animatedtk/refs/heads/main/logotk2
• api.github[.]com/repos/faviconicons2/images/contents/License
• api.github[.]com/repos/faviconicons2/images/contents/S3wfQWRnRraKMhvC/.txt
• api.github[.]com/repos/faviconicons2/images/contents/qKPJHGWmla3GrHhx/.txt

The two randomized .txt names came from separate executions and should be treated as per-run pivots, not permanent repository paths.

Host indicators

• %LOCALAPPDATA%\DellHeuristics.exe
• %LOCALAPPDATA%\Microsoft\DellHeuristics.zip
• scheduled task DellHeuristicsUpdate
• unexpected VBS or BAT files under %LOCALAPPDATA%
• a newly created VBS launcher in the user's Startup folder

Protocol and memory markers

• Readme9823, envvar-, ddvar-, respout-, filenm-, =boaval=, =boaformno=, git-config---ttsszz-, responseOut22-

Defensive lessons

Email teams should inspect password-protected Office attachments using passwords supplied in the same message where policy permits, preserve original EML evidence, and verify government-looking senders out of band. Endpoint teams should correlate Office processes spawning script hosts, new VBS/BAT files in user-writable paths, Startup-folder changes, and short-interval scheduled tasks. Network teams should review GitHub API access by uncommon native executables using process identity, request path, and endpoint lineage rather than treating GitHub as either automatically safe or automatically malicious.

Detection and hunting appendix

These are correlation leads, not standalone signatures. Validate them against host role, process lineage, user activity, and time.

For historical scoping, prioritize September 2025 email, proxy, DNS, firewall, EDR, Task Scheduler, and filesystem records. A September 2026 detonation is useful for capability analysis but cannot replace contemporaneous incident telemetry.

What the malware demonstrably did in the lab

The proof boundary should not be mistaken for an absence of malicious behavior. The retained runtime evidence shows that the process actively executed its network workflow:

• x64dbg stopped repeatedly inside WinHttpConnect, WinHttpOpenRequest, WinHttpSendRequest, WinHttpReceiveResponse, and WinHttpReadData for the analyzed process;
• register and stack values exposed the destination hosts, request methods, and paths at the time of the calls;
• a 65-byte bootstrap response was read from the raw GitHub path;
• the GitHub API License object returned Readme9823\n;
• credential-shaped material was absent from the earliest bounded memory search and present in later dumps from the same process instance; and
• PID 452 constructed an authenticated GitHub Contents API PUT, passed it to WinHttpSendRequest, and later reached WinHttpReceiveResponse;
• PID 1608 exposed the exact empty-content JSON body and the same-path verification GET, but both network calls were synthetically bypassed before transmission; and
• the final PID 1608 dump and breakpoint progression reached ExitProcess without exposing a separate non-GitHub command server.

Those observations establish runtime repository communication consistent with a remote control/check-in design, plus an attempted remote write in PID 452. They do not establish that the implant received and executed an operator command. The PID 1608 body shows an empty-file check-in rather than captured exfiltration content, but the retained screenshots still do not establish whether GitHub accepted the earlier PID 452 write. No separate dedicated C2 was observed in the captured execution stage, although dormant, encoded, or conditionally selected endpoints remain possible.

What remains unproven

The retained evidence does not establish which recipients received or opened the email, whether the full persistence chain completed on a production endpoint, whether the fallback IP was contacted in the captured run, the HTTP result of the PID 452 GitHub PUT, a resulting repository object, successful exfiltration, exclusive control of the shared IOC, the absence of every possible later C2 path, or direct SideWinder ownership of the campaign.

These are evidence gaps, not invitations to fill the story with assumptions.

Evidence that would close the remaining gaps

The next collection steps are specific. Each item below answers a defined question rather than repeating the existing analysis.

For a follow-up run, the most valuable immediate action is to capture the return path, not merely another API-entry screenshot. At each WinHttpSendRequest and WinHttpReceiveResponse call, record the request handle, set a breakpoint on the caller's next instruction, capture RAX and GetLastError, then call or observe WinHttpQueryHeaders for WINHTTP_QUERY_STATUS_CODE. For WinHttpReadData, preserve the output buffer only after the function returns and use the exact byte count written through lpdwNumberOfBytesRead.

If historical endpoint or network logs are available, collect them before another live execution. They are more likely to answer what happened in September 2025 than a modern rerun against potentially expired infrastructure.

Conclusion

The case is best understood as a campaign investigation, not an isolated executable review.

A pension-themed spear-phishing email used institutional trust and a password-protected Word attachment to deliver an embedded executable. The document contained a staged persistence chain, while runtime evidence showed the implant using public services for network discovery, a Myanmar country gate, bootstrap material, and GitHub API operations. The resolved empty-file PUT and same-path GET are consistent with GitHub acting as the observed remote control/check-in infrastructure. No separate dedicated C2 was observed before ExitProcess, but this bounded run does not prove that no conditional or encoded endpoint exists. The exact IP overlap with a pre-existing Bangladesh e-GOV CIRT phishing IOC connects the case to wider regional activity more concretely than TTP similarity alone.

SideWinder is a reasonable intelligence hypothesis because public reporting describes sustained, document-led government targeting across the same region, including Myanmar. But hypothesis is not attribution. Until unique infrastructure, malware lineage, operator accounts, or other high-specificity evidence closes the gap, this incident should be reported as a Myanmar-focused spear-phishing case with confirmed regional IOC overlap and a possible SideWinder connection.

Public references

• Bangladesh e-GOV CIRT, *Phishing Campaign on Cyber Space of Bangladesh*, 6 August 2025.
• Hunt.io, *Operation SouthNet: SideWinder Expands Phishing and Malware Operations in South Asia*, 1 October 2025.
• Bangladesh e-GOV CIRT, *SideWinder Spear-Phishing Campaign Against Bangladesh Leveraging Dual-Format Weaponized Documents*, 30 July 2026.

Research note

This article is based on retained local case evidence and public reporting available through 10 September 2026. Indicators are defanged. Sensitive identities, raw dumps, live credentials, and reusable secrets are intentionally excluded. Static findings, intended execution paths, observed runtime behavior, remote outcomes, and actor attribution are kept as separate claims.