Home Upgrade Search Memberlist Extras Hacker Tools Award Goals Help Wiki Contact

Infostealer: Clean or Reinstall?

I've seen pretty different opinions on this, and I think the question gets more interesting once we separate removing the malware from recovering from the compromise.

Let's say we know an infostealer was actually executed. This isn't a questionable file that got quarantined before execution — the payload ran, and later Defender or another AV detected and removed it.

At that point, would you:

A) Remove the detected malware, investigate persistence, perform additional scans, verify the system looks clean, and continue using Windows.

or

B) Consider the installation untrusted, preserve necessary data, wipe/reinstall Windows, and rebuild from a known-good state.

I'm increasingly leaning toward B for a confirmed infostealer, especially on a machine used for important accounts.

The executable isn't necessarily the biggest problem

Once an infostealer executes, the question isn't just:

"Is the malicious EXE still on the computer?"

It's also:

"What information left the computer while it was running?"

Depending on the stealer, potentially exposed data could include:

browser passwords
cookies/session tokens
cryptocurrency wallets
email accounts
Discord/other messaging sessions
Steam/gaming accounts
API keys
SSH keys
developer credentials
saved autofill information
authentication/recovery data

Deleting the malware doesn't undo information that may already have been exfiltrated.

Session/token theft makes recovery harder

People commonly say:

"Change your password and enable 2FA."

That's good advice, but it may not cover everything.

If session information was stolen, I'd also be thinking about:

changing passwords
revoking active sessions
signing out all devices
reviewing trusted devices
checking recovery email/phone settings
reviewing authorized applications
removing suspicious OAuth access
rotating API/application tokens
regenerating recovery codes
checking recent login activity

I'd also do that from a known-clean device, rather than entering fresh credentials into the potentially compromised machine.

What does "AV removed it" actually prove?

This is where I struggle with option A.

An AV result may establish:

"A known malicious object was detected and remediated."

That's not necessarily the same as proving:

"Nothing else executed, no additional payloads were downloaded, no persistence remains, and every system modification has been identified."

If I was attempting to clean and investigate instead of immediately reinstalling, I'd probably use several tools rather than trusting one scanner.

Tools I'd check with

Microsoft Defender / Defender Offline

full system scan
offline scan for threats that may interfere while Windows is running

Microsoft Sysinternals Autoruns

startup entries
services
scheduled tasks
logon persistence
browser/helper entries
other autostart locations

Process Explorer

inspect running processes
parent/child relationships
unusual executable locations
signatures and process properties

Process Monitor

watch file, registry, process, and persistence-related activity

TCPView

inspect active network connections and which processes own them

Windows Task Scheduler

manually inspect suspicious scheduled tasks

Services / services.msc

inspect newly created or suspicious services

Task Manager

startup applications
unusual processes
resource activity

Event Viewer

logon events
service creation
crashes
security-related events
suspicious activity around the suspected infection time

Malwarebytes

useful as a second-opinion malware/adware scan

ESET Online Scanner

another independent second-opinion scan

VirusTotal

useful for checking suspicious file hashes/files and comparing detections

I wouldn't treat:

"Five scanners say clean"

as absolute proof that the machine is trustworthy, though.

Tools can help build confidence, but they can't necessarily prove the absence of something you don't know to look for.

Questions I'd want answered

If the original stealer definitely executed:

Was it only an infostealer?

Did it download another payload?

Did it establish persistence?

Were scheduled tasks or services created?

Did it modify Defender/security settings?

Was it running as a standard user or administrator?

Was UAC bypassed?

How long was it active?

Was browser/session data accessible?

Do we know the entire infection chain?

That's a much higher bar than running multiple scanners until everything reports clean.

Cleaning vs restoring trust

I think there are really two different goals.

Goal 1: Remove known malware.

Goal 2: Restore confidence that the operating system can be trusted.

Those aren't necessarily the same thing.

For an analyst, keeping the machine intact for investigation makes sense.

For a normal personal PC, though, there eventually comes a point where trying to prove the absence of unknown persistence takes more work than rebuilding the system.

My recovery approach would probably be

1. Isolate the machine.

Disconnect it from the network and stop using it for sensitive accounts.

2. Determine what may have been exposed.

Especially:

email
password manager
browser accounts
financial accounts
crypto
Discord
Steam
cloud storage
developer credentials/API keys

3. Recover critical accounts from another trusted device.

I'd prioritize:

Primary email → password manager → financial accounts → cloud accounts → everything else

4. Revoke sessions.

Don't assume a password reset automatically invalidates every session everywhere.

5. Rotate credentials and secrets.

Including:

passwords
API keys
application tokens
SSH keys where appropriate
recovery codes
other exposed authentication material

6. Investigate the infected machine if useful.

I'd probably check:

Defender Offline
Autoruns
Process Explorer
Process Monitor
TCPView
scheduled tasks
services
Event Viewer
secondary malware scanners

7. Preserve personal files carefully.

Documents, photos, source code, etc.

I'd avoid blindly copying:

.exe
.scr
.bat
.cmd
random archives
unknown installers

from the compromised system.

8. Reinstall Windows from trusted installation media.

For a confirmed executed infostealer, this is probably where I'd personally land.

9. Fully update Windows and applications.

10. Restore only trusted data.

11. Continue monitoring important accounts afterward.

Reinstalling solves the endpoint trust problem.

It does not undo anything that was stolen before the reinstall.

When I'd be more comfortable cleaning instead

I wouldn't say every malware detection requires wiping Windows.

I'd be much more comfortable cleaning if:

the malicious file never executed
it was quarantined before execution
the infection is extremely well understood
privileges were limited
telemetry shows exactly what occurred
there was no credential/session theft capability
persistence can be confidently ruled out

But a confirmed executed infostealer is different.

Its main objective may have been completed within seconds of execution.

Where do you draw the line?

If an infostealer is confirmed to have executed, what would make you comfortable trusting that Windows installation again?

Would something like:

Defender Offline + Autoruns + Process Explorer + secondary scanners + manual persistence checks

be enough for you?

Does the specific malware family determine the answer?

Would admin privileges automatically push you toward a reinstall?

Or do you treat confirmed infostealer execution as:

wipe/reinstall + revoke sessions + rotate credentials

by default?

Interested in hearing from people who have actually handled infostealer infections and what tools/workflow you rely on.
If I know that there was an infostealer specifically, I would assume no persistence. What threat actor tries to steal logins multiple times from the same person?
There is no right or wrong answer, because it depends on the specific situation.

Sometimes, people just want to get on with their lives and they do the reinstall route.

Other times, they may prefer a removal instead of a reinstall.
Good points from both of you.

@DramaKing — I actually agree that if I knew with confidence the only thing that executed was a pure smash-and-grab infostealer, persistence wouldn't be my default assumption.

A lot of stealers don't necessarily benefit from sitting there forever.

Once they've grabbed:
browser credentials
cookies/session tokens wallets
autofill data system information

and sent the log out, the initial objective is already complete.

Microsoft has even documented StealC typically deleting itself after exfiltration, which fits exactly with what you're saying.

Where I'd hesitate is assuming:

“Infostealer detected = therefore the entire infection was non-persistent.”

To me there are two separate questions:

1. Did the stealer itself persist?

Probably not necessarily.

2. Was the stealer the only thing that executed?

That's the part I'd want confidence in before trusting the install.

For example, Lumma isn't limited to stealing information; Microsoft documents it as also being capable of installing other malware.

And Microsoft recently documented campaigns where Amadey acts as a loader while StealC handles the information theft. In that situation, seeing the stealer doesn't automatically tell you everything else the delivery chain did.

So I think I'd change my original wording from:

> “Infostealer executed, therefore assume persistence.”

to:

> “Infostealer executed, therefore determine whether it was a standalone stealer or part of a larger infection chain.”

That's probably the more accurate way to look at it.

And @5chn4pp, I agree with you too.

I don't think there can really be a universal:

malware = reinstall

rule.

A lot depends on what machine we're talking about.

If it's someone's gaming PC with good backups and they just want confidence quickly, reinstalling may take less time than spending hours investigating it.

If it's:

a business workstation a forensic case
a machine with specialized software a system where evidence matters
something where reinstalling would cause major downtime

then investigating/remediating becomes much more attractive.

I'd probably base the decision on something like:

Known payload?
Known initial access vector?
Any loader/downloader involved?
Privilege level?
Evidence of persistence?
Any security controls modified?
How valuable/sensitive is the system?
Do I have trustworthy backups?
How confident am I that I understand the full execution chain?

The more of those that are unknown, the more attractive a reinstall becomes to me.

So I'm starting to think the real dividing line isn't:

Infostealer = wipe or clean?

It's:

How much uncertainty about the compromise are you willing to accept before rebuilding becomes cheaper than proving the system trustworthy?

That's probably a better version of the question I was originally trying to ask.
(Aug 17, 2026 11:01 AM)boondox420 Wrote:  How much uncertainty about the compromise are you willing to accept before rebuilding becomes cheaper than proving the system trustworthy?

That's probably a better version of the question I was originally trying to ask.

There can be no uncertainty. You need to sleep tight at night, knowing everything is good.

If you’re working with a qualified analyst with a decade of malware-removal experience, their assessment should be enough to determine whether you need to go ahead and reinstall or can confidently declare the device clean.
Definitely Option B all day. Once an infostealer executes, that OS is permanently untrusted.

Even if 5 scanners say clean, you can't easily detect custom persistence or registry tweaks. The real nightmare isn't even the malware file itself, it's the active session tokens they already exfiltrated.

Wipe the drive, reinstall from a clean USB, and change all passwords/revoke sessions from a completely different device. Anything else is just gambling.
(Aug 22, 2026 05:03 PM)psycheuser Wrote:  The real nightmare isn't even the malware file itself, it's the active session tokens they already exfiltrated.

The real nightmare is people who use AI to give advice on malware, when they have no knowledge on the topic.
(Aug 23, 2026 09:51 AM)5chn4pp Wrote:  The real nightmare is people who use AI to give advice on malware, when they have no knowledge on the topic.
New to the forum, not the industry, man. If you think session hijacking via stolen tokens isn't the biggest threat in modern infostealer triage, you haven't done real corporate IR work. 
Malware files get nuked by basic EDR or standard AV every day, but valid session cookies bypass MFA entirely and let threat actors walk right into active infrastructure. Ask any enterprise analyst—token theft is the whole reason infostealers are a billion-dollar black market right now. 
Call it AI slop if you want, but the technical reality stands: if your tokens are gone, a clean AV scan doesn't save your accounts.
(Aug 24, 2026 11:41 AM)psycheuser Wrote:  New to the forum, not the industry, man. If you think session hijacking via stolen tokens isn't the biggest threat in modern infostealer triage, you haven't done real corporate IR work. 
Malware files get nuked by basic EDR or standard AV every day, but valid session cookies bypass MFA entirely and let threat actors walk right into active infrastructure. Ask any enterprise analyst—token theft is the whole reason infostealers are a billion-dollar black market right now. 
Call it AI slop if you want, but the technical reality stands: if your tokens are gone, a clean AV scan doesn't save your accounts.

1. Session hijacking via stolen tokens is not the biggest threat modern infostealer triage. It ranks as the second most common initial access vector at 16%. Vulnerability exploitation at 33% ranks first.

Source: https://cloud.google.com/blog/topics/thr...rends-2025

2. Please state your source for "token theft is the whole reason infostealers are a billion-dollar black market". You are being hyperbolic, implying that token theft alone is “the whole reason” for their value.

3. Modern enterprises use conditional access, for example in Entra ID, which requires compliant / hybrid-joined devices, CAE + strict network/location controls, and even token protection / device-bound tokens. Your scenario where infostealers steal sessions and then nukes itself falls short when we talk actual enterprise.

4. Can you even form an argument without using AI?
It's best to reinstall.


Possibly Related Threads...
Thread / Author Replies Views Last Post
by Tha SneakMar 13, 2025 05:08 PM 8 287 Mar 13, 2025 05:08 PM
Last Post: Novo
[Infected] by ailoDec 31, 2016 02:24 AM 2 155 Dec 31, 2016 02:24 AM
Last Post: Hackoo
by Beesting EnterprisesMay 18, 2016 01:31 AM 3 87 May 18, 2016 01:31 AM
Last Post: Leroy Jethro Gibbs