Recovering files after a Trojan cryptographer
At the end of the working day, the accountant of one of the enterprises received an e-mail from the counterparty, which was constantly in business correspondence, a letter containing an attached file, referred to as “Act of reconciliation.xls”. When trying to open visually nothing happened from the point of view of an accountant. Repeating the opening attempt several times, the accountant made sure that excel is not going to open the file sent. Having unsubscribed to the counterparty about the impossibility to open the file received by her, the accountant, pressed the PC shutdown button, and, without waiting for the PC to finish working, left the workplace. Coming in the morning, I found that the computer had not turned off. Without giving it much importance, I tried to start a new working day, habitually clicking on the 1C Account label, but after selecting the base I expected an unpleasant surprise.
rice one
Subsequent attempts to start a working environment 1C also failed. The accountant contacted the company servicing the computing equipment of their organization and requested technical support. Specialists of the service organization found out that the problems are much more extensive, since, apart from the fact that the 1C Accounting 7.7 database files were encrypted and had the extension “BLOCKED”, the files with the doc, docx, xls, xlsx, zip, rar, 1cd and others. A text file was also found on the user's desktop, which reported that the files were encrypted using the RSA 2048 algorithm, and that it was necessary to pay for the ransomware services to get the decoder. Backup 1C databases was carried out daily to another hard disk installed in the same PC in the form of creating a zip archive with a folder of 1C databases, and a copy of the archive was placed on a network drive ( NAS ). Since there were no restrictions on access to backups, the malicious software had access to them.
Having assessed the scale of the problem, the service organization specialists copied only the encrypted files to a separate drive and reinstalled the operating system. Also, emails containing malware have been removed from the accountant’s mailbox. Attempts to decrypt using popular anti-virus company decoders at that time did not produce a result. At this service organization the company has completed its work.
')
Prospects to start with the input of primary documents in the new 1C database, accountants are not very pleased. Therefore, further possibilities of recovering encrypted files were considered.
Unfortunately, the original malware body and the message of the extortioner were not saved, which did not allow disassembling the body and establishing the algorithm of its operation through analysis in the debugger. It was also not possible to check whether he met various antivirus companies.
Therefore, immediately proceed to the analysis of files whose structures are well known. In this case, it is convenient to use for analyzing DBF files from the 1C database, since their structure is very predictable. Take the file 1SENTRY.DBF.BLOCKED (journal of accounting entries), the size of this file is 53,044,658 bytes
rice 2
Considering the encrypted DBF file, we draw attention to the fact that the first 0x35 bytes are not encrypted, since there is a header specific to this type of files, and we observe part of the description of the first field of the record. Let's calculate the file size. To do this, take: WORD at offset 0x08, the content of which is 0x04C1 (it contains the size of the DBF file header), WORD at offset 0x0A, the content of which is 0x0130 (it contains the size of one record in the database), DWORD at offset 0x04, the contents of which is 0x0002A995 (the number of records), and 0x01 is the size of the final marker. Let's solve an example: 0x0130 * 0x0002A995 + 0x04C1 + 1 = 0x0032965B2 (53 044 658) bytes. The file size, according to the file system record, corresponds to the calculated one based on the information in the DBF file header. Perform similar checks for several DBF files and make sure that the file size has not been changed by malware.
Analyzing the contents of DBF shows that small files starting at offset 0x35 are encrypted in their entirety, but large files are not.
rice 3
Account numbers, dates and amounts are changed so as not to violate confidentiality agreements, including in the encrypted area.
Starting at offset 0x00132CB5, we detect the absence of signs of encryption to the end of the file, by performing checks in other large files, we confirm the assumption that only files less than 0x00132CB5 (1,256,629) bytes are completely encrypted. Many malware authors perform partial file encryption to reduce the time it takes to distort user data. They are probably guided by the fact that their malicious code in the shortest time causes the greatest possible damage to the user.
Let's start analyzing the encryption algorithm
rice four
In fig. 4 in place of the DBF file header field there are almost identical sequences of 16 bytes (offset 0x50, 0x70, 0x90), we also see partial repetition of sequences of 16 bytes (offset 0x40.0x60.0x80), in which there are differences only in bytes, where register the field name and field type.
Based on this observation, having a small understanding of the algorithms for the operation of cryptographic algorithms like AES , RSA , one can make an unequivocal conclusion that the data is not encrypted using these algorithms. That is, information about the encryption algorithm submitted by the customer is unreliable. Inaccurate, it may be due to some erroneous conclusions of the customer, or be the result of the malware fraud by the author. We cannot verify this, since only encrypted files are available to us.
Based on the structure of the DBF file headers and changes in bytes in the sequences, it can be assumed that encryption was performed using XOR operations on data with a certain pattern. You can also make an assumption, based on the length of the repeating sequences, that the pattern length is 16 bytes (128 bits). The base header is 0x04C1 bytes, the size of the description of one field in the header is 0x20 (32) bytes. From this it follows that the header of this DBF file contains (0x4C1-0x21) / 0x20 = 0x25 (37) field descriptions. In fig. 4 underlined in red fragments of records of two fields starting at offset 0x10, which in case of 1C usually have zero values, except for 0x10 itself (since the offset indicates the size of the field), based on this, we can assume that we already have 15 of 16 bytes of the key encryption 0x97 0x99 0xE6 0xBF 0x4B 0x6C 0x77 0x76 0x3A 0x80 0x0B 0xXX 0xAF 0x45 0x6A 0xB7.
To find the last byte in the key, take another fragment of the same DBF file.
rice five
In Figure 5, we draw attention to the zero column, more precisely to its unencrypted part, and we see that the value 0x20 prevails there (space code according to the ASCII table). Accordingly, some identical value will prevail in the encrypted part of the column. It is easy to notice that this is 0xFA. To obtain the original value of the missing key byte, you must perform 0xFA xor 0x20 = 0xDA.
Substituting the obtained value on the missing position, we get the full key 0x97 0x99 0xE6 0xBF 0x4B 0x6C 0x77 0x76 0x3A 0x80 0x0B 0xDA 0xAF 0x45 0x6A 0xB7.
After performing the xor procedure, operations with the received key on encrypted sections received the original contents of the file.
rice 6
For the final control, we will perform a zip archive decryption operation, then unpack the archive. If all files were extracted and there was no CRC error for any file, then you can finally confirm the correctness of the key. And the final step will be unpacking the rest of the files according to the technical specifications.
This example suggests that probably not all the statements of the authors of malicious software are true. And it is often possible to solve the problem of recovering user data by analyzing the changed data.
Along with such simple cases, there are crypto-Trojans who will actually use modern cryptographic algorithms and, in the event of their attack, such a simple solution is in principle impossible. Therefore, be extremely careful when opening any files received by e-mail, even from trusted sources. Update your antivirus software regularly and back it up so that your data in all copies is not accessible to anyone at a time.
Next post: Recovering Data from a Damaged RAID Array to a Linux NAS
Previous publication: Restoring 1C Enterprise (DBF) database after formatting
rice one
Subsequent attempts to start a working environment 1C also failed. The accountant contacted the company servicing the computing equipment of their organization and requested technical support. Specialists of the service organization found out that the problems are much more extensive, since, apart from the fact that the 1C Accounting 7.7 database files were encrypted and had the extension “BLOCKED”, the files with the doc, docx, xls, xlsx, zip, rar, 1cd and others. A text file was also found on the user's desktop, which reported that the files were encrypted using the RSA 2048 algorithm, and that it was necessary to pay for the ransomware services to get the decoder. Backup 1C databases was carried out daily to another hard disk installed in the same PC in the form of creating a zip archive with a folder of 1C databases, and a copy of the archive was placed on a network drive ( NAS ). Since there were no restrictions on access to backups, the malicious software had access to them.
Having assessed the scale of the problem, the service organization specialists copied only the encrypted files to a separate drive and reinstalled the operating system. Also, emails containing malware have been removed from the accountant’s mailbox. Attempts to decrypt using popular anti-virus company decoders at that time did not produce a result. At this service organization the company has completed its work.
')
Prospects to start with the input of primary documents in the new 1C database, accountants are not very pleased. Therefore, further possibilities of recovering encrypted files were considered.
Unfortunately, the original malware body and the message of the extortioner were not saved, which did not allow disassembling the body and establishing the algorithm of its operation through analysis in the debugger. It was also not possible to check whether he met various antivirus companies.
Therefore, immediately proceed to the analysis of files whose structures are well known. In this case, it is convenient to use for analyzing DBF files from the 1C database, since their structure is very predictable. Take the file 1SENTRY.DBF.BLOCKED (journal of accounting entries), the size of this file is 53,044,658 bytes
rice 2
Considering the encrypted DBF file, we draw attention to the fact that the first 0x35 bytes are not encrypted, since there is a header specific to this type of files, and we observe part of the description of the first field of the record. Let's calculate the file size. To do this, take: WORD at offset 0x08, the content of which is 0x04C1 (it contains the size of the DBF file header), WORD at offset 0x0A, the content of which is 0x0130 (it contains the size of one record in the database), DWORD at offset 0x04, the contents of which is 0x0002A995 (the number of records), and 0x01 is the size of the final marker. Let's solve an example: 0x0130 * 0x0002A995 + 0x04C1 + 1 = 0x0032965B2 (53 044 658) bytes. The file size, according to the file system record, corresponds to the calculated one based on the information in the DBF file header. Perform similar checks for several DBF files and make sure that the file size has not been changed by malware.
Analyzing the contents of DBF shows that small files starting at offset 0x35 are encrypted in their entirety, but large files are not.
rice 3
Account numbers, dates and amounts are changed so as not to violate confidentiality agreements, including in the encrypted area.
Starting at offset 0x00132CB5, we detect the absence of signs of encryption to the end of the file, by performing checks in other large files, we confirm the assumption that only files less than 0x00132CB5 (1,256,629) bytes are completely encrypted. Many malware authors perform partial file encryption to reduce the time it takes to distort user data. They are probably guided by the fact that their malicious code in the shortest time causes the greatest possible damage to the user.
Let's start analyzing the encryption algorithm
rice four
In fig. 4 in place of the DBF file header field there are almost identical sequences of 16 bytes (offset 0x50, 0x70, 0x90), we also see partial repetition of sequences of 16 bytes (offset 0x40.0x60.0x80), in which there are differences only in bytes, where register the field name and field type.
Based on this observation, having a small understanding of the algorithms for the operation of cryptographic algorithms like AES , RSA , one can make an unequivocal conclusion that the data is not encrypted using these algorithms. That is, information about the encryption algorithm submitted by the customer is unreliable. Inaccurate, it may be due to some erroneous conclusions of the customer, or be the result of the malware fraud by the author. We cannot verify this, since only encrypted files are available to us.
Based on the structure of the DBF file headers and changes in bytes in the sequences, it can be assumed that encryption was performed using XOR operations on data with a certain pattern. You can also make an assumption, based on the length of the repeating sequences, that the pattern length is 16 bytes (128 bits). The base header is 0x04C1 bytes, the size of the description of one field in the header is 0x20 (32) bytes. From this it follows that the header of this DBF file contains (0x4C1-0x21) / 0x20 = 0x25 (37) field descriptions. In fig. 4 underlined in red fragments of records of two fields starting at offset 0x10, which in case of 1C usually have zero values, except for 0x10 itself (since the offset indicates the size of the field), based on this, we can assume that we already have 15 of 16 bytes of the key encryption 0x97 0x99 0xE6 0xBF 0x4B 0x6C 0x77 0x76 0x3A 0x80 0x0B 0xXX 0xAF 0x45 0x6A 0xB7.
To find the last byte in the key, take another fragment of the same DBF file.
rice five
In Figure 5, we draw attention to the zero column, more precisely to its unencrypted part, and we see that the value 0x20 prevails there (space code according to the ASCII table). Accordingly, some identical value will prevail in the encrypted part of the column. It is easy to notice that this is 0xFA. To obtain the original value of the missing key byte, you must perform 0xFA xor 0x20 = 0xDA.
Substituting the obtained value on the missing position, we get the full key 0x97 0x99 0xE6 0xBF 0x4B 0x6C 0x77 0x76 0x3A 0x80 0x0B 0xDA 0xAF 0x45 0x6A 0xB7.
After performing the xor procedure, operations with the received key on encrypted sections received the original contents of the file.
rice 6
For the final control, we will perform a zip archive decryption operation, then unpack the archive. If all files were extracted and there was no CRC error for any file, then you can finally confirm the correctness of the key. And the final step will be unpacking the rest of the files according to the technical specifications.
This example suggests that probably not all the statements of the authors of malicious software are true. And it is often possible to solve the problem of recovering user data by analyzing the changed data.
Along with such simple cases, there are crypto-Trojans who will actually use modern cryptographic algorithms and, in the event of their attack, such a simple solution is in principle impossible. Therefore, be extremely careful when opening any files received by e-mail, even from trusted sources. Update your antivirus software regularly and back it up so that your data in all copies is not accessible to anyone at a time.
Next post: Recovering Data from a Damaged RAID Array to a Linux NAS
Previous publication: Restoring 1C Enterprise (DBF) database after formatting
Source: https://habr.com/ru/post/327618/
All Articles