Defender unable to clear viruses

[qim]

Good morning, Al

I am a "little" confused about what I should do.

I created a Notepad file that isolates all mentions of .pdf but cannot decide what is valid or not

May I upload the file to you?

 

[ChatGPT]

Yes — please upload it.
If you’ve already attached the Notepad/text file here, I can review it from that. I can see from the thread history that you created a separate file isolating the .pdf references and wanted to share it for review
A few tips before uploading:

1. Text is best
   A .txt file is ideal.
2. Keep it focused
   If possible, include only:
   • the .pdf reference lines
   • a little text above and below each one
   • any nearby Subject:, From:, or Date: lines
3. Do not worry if you already uploaded it
   If it is already here, I’ll work from that.

Once it’s uploaded, I’ll help you sort:

• what looks normal
• what looks suspicious
• and what, if anything, you should remove.

 

[qim]

Here it goes

 

[ChatGPT]

Yes — please do.
I can see from the thread context that you created a text file isolating the .pdf references from the Thunderbird mailbox and wanted to share it for review
If the upload has already gone through, I’m ready to help sort out:

1. which entries look normal
2. which ones look suspicious
3. and which email(s), if any, you should remove

If I still can’t read the uploaded file directly on my side, the easiest fallback is:

1. paste a small sample here
2. or attach a .txt file with only:
   • the .pdf lines
   • a few lines above and below each
   • any nearby Subject:, From:, and Date: lines

Go ahead.

 

[qim]

Because there is no date in the entries, they could be anything up to more than 15 years old....

The first two (comprovativo) are possibly about confirmation of money transfers that I received. I expected them to be mine after paying something
The last two appear to be about information I may have requested about bank accounts


Now that i look at what I sent i am surprised to see more than one that do not include .pdf, i.e.
filename="smime.p7s"

 

[ChatGPT]

Good morning, Qim —
Yes, I saw that. And what you’re describing actually helps.

Short answer​

• smime.p7s is usually normal — it is commonly an S/MIME digital signature attachment, not the document itself.
• If the entries you isolated look like money transfer confirmations or bank information you deliberately requested, they may well be legitimate emails.
• The problem is that ESET is flagging something inside old Thunderbird mailbox content, not necessarily a live Windows infection. That matches what we already narrowed down earlier: the detections are in Thunderbird mailbox files, not normal Windows system locations

Why this is confusing​

Thunderbird stores many messages inside one mailbox file like Inbox, so you are not looking at neat individual attachments in Explorer. We already established that the Inbox file is one big mailbox container, not a folder of separate emails
That means:

1. a line mentioning .pdf does not automatically mean it is malicious
2. a line mentioning smime.p7s does not automatically mean it is malicious either
3. without the nearby Subject / From / Date, it is hard to judge whether the message is expected or suspicious

My view from what you said​

If:

• the first two look like expected payment confirmations
• the last two look like bank info you asked for
• and current Defender scans are clean

then I would not rush to delete those messages blindly.

Best next step​

Yes — upload the text file if you can.
What will help most is the file that shows:

• the .pdf references
• a few lines above and below
• especially any nearby:
  • Subject:
  • From:
  • Date:
  • filename=

That will let me help you separate:

• likely legitimate old mail
• suspicious old mail
• normal signature attachments like smime.p7s

About smime.p7s​

That specific filename is commonly:

• a cryptographic signature file
• added to signed email
• often harmless by itself

So seeing filename="smime.p7s" is not the same as seeing a suspicious PDF payload.

Recommendation for now​

1. Do not delete anything yet
2. Upload the text file
3. I’ll help you decide what is worth keeping and what is worth removing

And just to reassure you: based on everything so far, this still does not look like an urgent active infection on the PC; it looks like old email content stored in Thunderbird

 

[qim]

Also, I can´t find the original where I got the -pdf from....

 

[ChatGPT]

That’s OK, Qim — and from what you’ve described, I would not delete anything yet.
A few points:

1. smime.p7s is usually normal​

That filename is commonly an S/MIME email signature attachment, not the document itself. So seeing filename="smime.p7s" in your extracted text is not automatically suspicious. It often appears with legitimate signed mail.

2. Your own description sounds plausible​

You said the first two comprovativo items may be payment confirmations you expected, and the last two may be bank-account information you requested. That makes it quite possible these are legitimate old emails, not messages you should remove blindly.

3. Not finding the “original .pdf” is not surprising​

Because Thunderbird stores many messages inside one mailbox file like Inbox, the .pdf references can be buried inside that mailbox container rather than existing as separate files in Explorer. We already established that the Thunderbird Inbox is a single mailbox file, not a folder of separate emails

4. The bigger picture is still reassuring​

The detections ESET found are still consistent with old malicious or suspicious email content stored in Thunderbird mailbox files, not an active Windows infection. That matches the earlier narrowing-down we did in the thread

What I suggest now​

Since the entries may be valid and smime.p7s is often normal:

1. Do not delete anything yet
2. If possible, paste here just 2–4 short blocks from your extracted text, especially ones that include:
   • Subject:
   • From:
   • filename=
   • and any nearby .pdf line
3. I’ll help you judge which ones look normal and which ones deserve more suspicion

If you prefer, you can also paste:

• the first 2 comprovativo blocks
• and the last 2 bank-info blocks

That should be enough to review without going through everything.

 

[qim]

I am totally confused

The file that I uploaded looks different from the one I have on the Desktop- I am uploading it again, ALL entries end in .pdf

I dragged this one and now cannot open it. Do the 16 entries ALL end in .pdf?

Are both these the same? They sould be

 

[ChatGPT]

Yes — that part makes sense now.

Why your text file shows non-.pdf entries​

The file you created was not a pure “PDF-only” extract.
Earlier, the PowerShell command we used searched for all of these patterns:

• .pdf
• Content-Type: application/pdf
• filename=
• Subject:
• From:
• Date:

So the output file can contain lines like:

• filename="smime.p7s"
• Subject: ...
• From: ...

even if they do not end in .pdf.
That is expected.

Why you cannot find the “original PDF”​

Also expected.
Thunderbird stores many emails inside one big mailbox file like Inbox, not as neat separate attachments in Explorer. We already established that the Thunderbird Inbox is a single mailbox file, not a folder of individual messages or PDFs
So there may be:

• no standalone .pdf file for you to find in Windows
• only references to a PDF attachment inside an old email message stored in Inbox.OLD

About smime.p7s​

That filename is usually normal. It is commonly an S/MIME digital signature attachment, not the actual PDF document.
So seeing filename="smime.p7s" does not mean that entry is malicious by itself.

Short answer to your main question​

No — the 16 entries do not all have to end in .pdf.
Because the search file includes broader matches like filename=, Subject:, From:, and Date: as well as .pdf references

What I suggest now​

1. Do not worry about not finding a separate original .pdf.
2. Do not delete anything yet.
3. If you want, paste here 2 or 3 short blocks from the text file that include:
   • one Subject:
   • one From:
   • one filename=...
   • and one nearby .pdf line

That will be enough for me to help judge whether those entries look like:

• legitimate old bank/payment emails
• or suspicious emails worth removing.

From what you’ve already said — payment confirmations and requested bank info — they may well be legitimate old mail, so I would not rush.

 

[qim]

Do you mean from the file where I extracted the .pdf mentions?

like this:
AppData\Roaming\Thunderbird\Profiles\cricit3s.default\Mail\correu.andorra-1.ad\Inbox.OLD:1835:
d="pdf'?p7s'?scan'208,217,147";a="31820608"
AppData\Roaming\Thunderbird\Profiles\cricit3s.default\Mail\correu.andorra-1.ad\Inbox.OLD:2198:Content-Type:
application/pdf; name=comprovativo.pdf
AppData\Roaming\Thunderbird\Profiles\cricit3s.default\Mail\correu.andorra-1.ad\Inbox.OLD:2200:Content-Disposition:
attachment; filename=comprovativo.pdf
AppData\Roaming\Thunderbird\Profiles\cricit3s.default\Mail\correu.andorra-1.ad\Inbox.OLD:2372:bZxa83s0GR5Xal/7vUVkM9M16
tVIYPXjVPDf6iLztdrqvFZqzVbryONumaaZpnCJ4be1FXYrpzeF

 

[ChatGPT]

Yes — that explains the confusion.
You likely have two different text files:

1. a broader context file made from the command that searched for .pdf, Content-Type: application/pdf, filename=, Subject:, From:, and Date: — that file can include non-.pdf lines like filename="smime.p7s"
2. a narrower file where you isolated only the .pdf mentions yourself — in that one, the entries should all be tied to .pdf references

So, no, the entries do not all have to end in .pdf if they came from the broader PowerShell output. That broader file was never “PDF-only” — it was designed to include nearby email headers and filenames too

About the sample you pasted​

This part:

Content-Type: application/pdf; name=comprovativo.pdf
Content-Disposition: attachment; filename=comprovativo.pdf

does look like a real PDF attachment reference.
But this line:
d="pdf'?p7s'?scan'208,217,147"
does not by itself prove anything useful. It looks like miscellaneous encoded/content text. I would ignore that line unless it appears together with clear message headers.

Why the uploaded file may look different​

Most likely one of these happened:

1. you uploaded the broader context file
2. on the Desktop you were looking at the PDF-only extracted file
3. or you dragged the wrong one by accident

That would exactly explain why one file contains smime.p7s and the other appears to contain only .pdf references.

Practical answer​

If you want me to help judge the entries, the best file is the one that contains for each entry:

• Subject:
• From:
• Date:
• and the nearby .pdf lines

If the file you have now really contains 16 entries all tied to .pdf, that is fine — but I still need the nearby Subject / From / Date to tell whether they are likely legitimate payment/bank emails or not.

What to do next​

Please paste 2 or 3 full small blocks like this:

Subject: ...
From: ...
Date: ...
Content-Type: application/pdf; name=...
Content-Disposition: attachment; filename=...

The comprovativo.pdf example is a good start.
And yes: smime.p7s can still be completely normal.

 

[qim]

I have to go out and will return in the afternoon

But to sleep easier maybe I should export the Andorra files to another medium. That account was closed in june of last year and I made copies of it

I could then DELETE anything more than 3 years old and see if the issues disappear

 

[ChatGPT]

Yes — that is a sensible and safe plan.
If the Andorra account is closed, and you already have copies, then the easiest way to sleep easier is:

Best approach​

1. Back up the Andorra mailbox files to another medium
   • USB drive
   • external drive
   • another PC
2. Remove the old Andorra mailbox files from this PC
3. Run ESET again
4. See if the detections disappear

That is better than trying to judge hundreds of old messages one by one.

Even better than “older than 3 years”​

Because the account is already closed, I would not bother with age filtering first.
I would do this instead:

Option A — simplest​

1. Copy the whole folder:
   C:\Users\open1\AppData\Roaming\Thunderbird\Profiles\cricit3s.default\Mail\correu.andorra-1.ad
   to external storage
2. Confirm the copy is complete
3. Delete or move the original correu.andorra-1.ad folder off this PC
4. Run ESET again

If ESET no longer finds the Andorra detection, you have confirmed it was only in that archived mailbox.

If you prefer to be extra cautious​

Instead of deleting immediately:

1. Move the folder to a USB/external drive
2. Or rename the folder on the PC to something like:
   correu.andorra-1.ad.BACKUP
3. Then move it off the PC later

But note: if it stays on the PC, ESET may still scan it.

Important​

If your goal is to make ESET stop detecting it, the old mailbox data must be:

• deleted from this PC, or
• moved off this PC

Renaming alone is usually not enough.

About deleting only messages older than 3 years​

You can do that, but it is:

• more work
• less certain
• and unnecessary if the whole account is no longer used

So my recommendation is:

Recommended plan​

1. Export / copy Andorra mailbox folder to external storage
2. Remove the original from this PC
3. Run ESET
4. If only the Gmail-related detection remains, deal with that separately later

That is the safest and cleanest next step.
When you return this afternoon, if you want, I can give you the exact safest step-by-step for copying and removing the correu.andorra-1.ad folder.

 

[qim]

While I am still here

AS you know I renamed Inbox files InboxOLD.... and a new empty Inbox was created

If I rename the InboxOld, Inbox to get things back to where they were will that work?

What I have in mind is to isolate the issue by deleting older messages, bit by bit (after copying the lot to another medium) and scan to see at what stage the issue disappears

In Thunderbird it is very easy to delete large blocks by date

In fact, I have just realized that the Inbox only gors back to 2016. I must have changed the account´s name over the years

Just for your information, when Andorra Telecom told me at 2 week's notice that I could not maintain the account wirthout a local phone number, I copied the whole inbox to a different Thunderbird account: [email protected] and they are in a folder AndorraIN

 

[ChatGPT]

Yes — that can work, but there is one important catch:

Important catch​

If you restore Inbox.OLD back to Inbox, the old detections may reappear immediately, because you are putting the old mailbox content back where Thunderbird reads it.
That does not mean a new infection — only that the old stored message content is visible again.

Short answer​

Yes, you can rename Inbox.OLD back to Inbox, but only with Thunderbird closed.

Safe way to do it​

1. Close Thunderbird completely.
2. In the mailbox folder, rename the current empty Inbox to something like:
   • Inbox.EMPTY
3. Rename Inbox.OLD back to:
   • Inbox
4. Do the same for the index file if needed:
   • Inbox.msf.OLD back to Inbox.msf
5. Open Thunderbird.

Your “delete older messages bit by bit” idea​

Yes — that is a reasonable way to isolate the problem, especially since Thunderbird makes bulk deletion by date easy.

But there is a second important catch​

You just said you copied the whole old Andorra inbox into another Thunderbird account:

• [email][email protected][/email]
• folder AndorraIN

That means the same suspicious message may exist in two places:

1. the old Andorra Inbox
2. the copied AndorraIN folder in the Gmail account

So if you clean one copy but not the other, ESET may still find it.

Best practical plan​

1. Back up first​

Copy both of these to external storage before changing anything:

• the old Andorra mailbox
• the Gmail AndorraIN copy

2. Restore only one mailbox for testing​

Restore the Andorra Inbox.OLD back to Inbox as above.

3. Delete by date in Thunderbird​

Since the mailbox only goes back to 2016, you can prune in chunks.
I would suggest:

1. Delete the oldest large block first
2. Empty Trash
3. Run File > Compact Folders
4. Close Thunderbird
5. Run ESET
6. See whether the detection remains

4. If detection remains​

Repeat with the next block.

Better than “bit by bit”​

To save time, do it in large date ranges, for example:

1. delete 2016–2018
2. scan
3. if still detected, restore from backup if needed and try another range
4. or continue with 2019–2020

Very important​

Because the old Andorra mail was copied to AndorraIN, you may need to do the same cleanup there too.
Otherwise:

• detection disappears from old Andorra Inbox
• but remains in AndorraIN

My recommendation​

If your goal is to identify the bad message while keeping most old mail:

1. Back up both copies
2. Restore Inbox.OLD to Inbox
3. Delete old mail by date ranges, not one by one
4. Compact folders
5. Scan
6. If needed, repeat
7. Then remember to check AndorraIN too

Final note​

If you want, when you come back this afternoon, I can help you design the best date-range test order so you can narrow it down with the fewest scans.