StruxureWare DCE Back-Up Jobs

[BartZ]

At a customer of ours, a backup job runs every Friday night.

Only during the backup, the security scanner noticed that the following file was created: ....\opt\netbotz\data\ddfs\.revision.txt.4ImcRY

Is this normal behavior of a backup job, maybe a temporary file. Or is this possibly randsomeware?

They run StruxureWare version 7.9.0

Thanks in advance for your help!

[mwhelihan · Accepted solution]

Hello @BartZ,

Yes, it is always best to be cautious about potential ransomware. A few follow up questions:

1. Are you seeing any issues with DCE or the backups?
2. Can you confirm that the security scanner is flagging the file on your backup server and not the DCE server itself? We are assuming that it is on your backup server.

3. Is the .revision.txt.4lmcRY file always present or only present temporarily? It sounds like a temporary file created during backup, but it is likely not something that is present for a long time and we are having difficulty reproducing the creation of that file (or something like it) during a backup.

4. Are you able to open the .revision.txt.4lmcRY file and inspect the contents on a computer that is not connected to any network and you are ok exposing to a potentially malicious file?

[Shaun · Accepted solution]

Hi,

This is the usual behavior of the rsync utility.  When transferring the file "example.txt", it will create a file named example.txt.random - the random suffix is intended to prevent collisions. The contents are then transferred into this temporary file, and once it's complete, it's renamed to the intended "example.txt".

(This temporary file may be prefixed with a single dot to make it hidden on unix-like systems.  This is dependent on the rsync version.)

The purpose of this is to make transfers atomic - if you have an existing "example.txt", it won't be replaced until after the transfer is complete.  This stops disrupted transfers from leaving you with neither the previous version nor the transferred version - the result should either successful, or as if nothing happened, and never a broken half-way.

I can't speak to why your scanner might flag it - the only difference between this file and every other file creating during the backup, is that this one is tiny, so the temporary file is very short-lived.  But it's short-term existence is what I'd expect to see during (but not after) the backup.

(If you do choose to inspect this file, what I'd expect it to contain is 40 hexadecimal chars - a sha1sum that I presume identifies a revision out of a version control system. If the file is not 41 bytes, I'd consider that a red flag.)

The easiest way I can replicate this is to run a network capture on a backup running over nfsv3.  For each file I get create, setattr, write, commit & rename operations.  You can see the temporary name being used in the create operation, and the rename operation changing it to the expected filename.  It can be tough to catch them in the act otherwise, as they're very short-lived.

To be clear - I'm not suggesting there's nothing wrong - it'd be dangerous of me to do so.  I'm describing the behavior I expect to see, so you can see if it meshes with what you're actually seeing.

[BartZ]

Dear Shaun,

Thank you for your comprehensive and articulate answer!

We were already almost of the opinion that this was a temporary file that was short on the server and eventually becomes a final file with the correct extension.

I am afraid that exactly at the time of creation, the security scanner started scanning and came across this temporary file.

By this response, we know that no further (necessary) actions are required.

Thanks again!

[BartZ]

Hello Mwhelihan,

Thank you for your reply!

1. No there were no other problems with the backup. It was purely this file that set off the security scanner.
2. It is indeed that the security scanner flagged the file on the backup server as potentially randsomeware.
3. It was a temporary file if I also saw Shaun's reply on this forum. The temporary file was only deleted by the scanner though. In the previous backups, we also saw that the file was named \revision.txt. without the random characters.
4. Unfortunately, this file no longer exists because it was deleted immediately.

But it seems to be a temporary file that is only on the server for a short time and exactly at that time the security scanner may have performed a scan and encountered this file.