Dridex Hackers Zone

Certificate Size in Certificate Table The payload to be added in the test is: 1111111111, with a length of 10 Obviously, New Size = Old Size + Payload Size = 14640 +10 = 14650 = 393aH The data corresponding to the offset address 138000H-138003 is modified to 3A390000, as shown in the figure

The following information is available: File Size: 1292592 bytes PE Size: 1277952 bytes infer: The offset address of the Certificate Table is 138000H (1277952) The first four bytes of the Certificate Table store the length, and the size should be 14640 bytes (1292592-1277952) Now jump to the offset address 138000H, look at the first four bytes, and verify the inference As shown in the figure, the first four bytes are 30390000, and the actual length is 00003930H, which is 14640 bytes.

Use to CFF Explorerview the dll structure, as shown in the figure

Certificate Size in Certificate Table

Of course, although adding data at the end of the certificate will not affect the calculated hash of the file, it will change the length of the certificate, so the location where the length of the certificate is saved in the PE file structure needs to be modified accordingly (2 places in total). Intuitive way to add payload and modify certificate length Demo one Test file: ntdll.dll The default location under Win7 x64 is: C:\Windows\SysWOW64 use tools: CFF Explorer Hex Editor LordPE

If the content of the file is modified, the calculated hash of the file will change, causing the digital certificate to fail verification. Therefore, the digital certificate can ensure the integrity of the signed file, but there is a deficiency in the algorithm for calculating the hash of the file: The calculation of the file hash is not the calculation of the entire file content (such as step 4 of calculating the file hash, and the part with the gray background in Figure 1, the purpose is to prevent the bound certificate file from affecting the hash value) More notably: Adding data at the end of the Certificate Table will not affect the calculated file hash, that is to say, adding data at the end of the Certificate Table will not cause the certificate to be invalidated

Windows Authenticode Portable Executable Signature Format https://msdn.microsoft.com/en-us/windows/hardware/gg463180.aspx

Signing process: Calculate PE file hash Generate digital certificate based on hash The digital signature is added at the end of the file, this part is calledCertificate Table Steps to calculate the file hash: Load the image header into memory. Initialize a hash algorithm context. Hash the image header from its base to immediately before the start of the checksum address, as specified in Optional Header Windows-Specific Fields. Skip over the checksum, which is a 4-byte field. Hash everything from the end of the checksum field to immediately before the start of the Certificate Table entry, as specified in Optional Header Data Directories. Get the Attribute Certificate Table address and size from the Certificate Table entry. For details, see section 5.7 of the PE/COFF specification. Exclude the Certificate Table entry from the calculation and hash everything from the end of the Certificate Table entry to the end of image header, including Section Table (headers).The Certificate Table entry is 8 bytes long, as specified in Optional Header Data Directories. Create a counter called SUM_OF_BYTES_HASHED, which is not part of the signature. Set this counter to the SizeOfHeaders field, as specified in Optional Header Windows-Specific Field. Build a temporary table of pointers to all of the section headers in the image. The NumberOfSections field of COFF File Header indicates how big the table should be. Do not include any section headers in the table whose SizeOfRawData field is zero. Using the PointerToRawData field (offset 20) in the referenced SectionHeader structure as a key, arrange the table’s elements in ascending order. In other words, sort the section headers in ascending order according to the disk-file offset of the sections. Walk through the sorted table, load the corresponding section into memory, and hash the entire section. Use the SizeOfRawData field in the SectionHeader structure to determine the amount of data to hash. Add the section’s SizeOfRawData value to SUM_OF_BYTES_HASHED. Repeat steps 11 and 12 for all of the sections in the sorted table. Create a value called FILE_SIZE, which is not part of the signature. Set this value to the image’s file size, acquired from the underlying file system. If FILE_SIZE is greater than SUM_OF_BYTES_HASHED, the file contains extra data that must be added to the hash. This data begins at the SUM_OF_BYTES_HASHED file offset, and its length is: (File Size) – ((Size of AttributeCertificateTable) + SUM_OF_BYTES_HASHED)

Figure 1 quoted from Windows Authenticode Portable Executable Signature Format https://msdn.microsoft.com/en-us/windows/hardware/gg463180.aspx

PE file format and digital signature format

Tom NipravskyThis method was introduced in the BlackHat2016 topic from the Deep Instinct Research Team 《Certificate Bypass: Hiding and Executing Malware from a Digitally Signed Executable》, and a Reflective PE Loader was implemented to load the payload hidden in the digital certificate of the PE file, which is worth learning. Issue PDF download address: https://www.blackhat.com/docs/us-16/materials/us-16-Nipravsky-Certificate-Bypass-Hiding-And-Executing-Malware-From-A-Digitally-Signed-Executable-wp.pdf This article will introduce in more detail how to hide the payload in the PE file on the premise of ensuring the validity of the digital signature.

In order to verify the origin and integrity of PE files, digital certificates are often added to PE files. Under Windows system, Microsoft's digital signature will be added to some important files by default, such as ntdll.dll. During the static analysis of the PE file, the malicious file analysis system verifies the signature if the PE file has a digital signature. If the verification of the digital signature is passed, the subsequent analysis will not be performed. The main consideration for this is to reduce false positives and reduce server resource consumption. If the payload can be hidden in the PE file on the premise of ensuring the validity of the digital signature, then this steganography method will be very hidden.

Steganography Technique - Hiding Payload (virus) in the Digital Certificate of PE File

The hardest part of this is trying to find out how to get someone to open a registry key file

The way Windows executes EXE files is stored inside the registry. The way it executes JPG files is stored there too. This means that you need to make windows think a JPG file is an EXE file. But we cant do that without hurting the OS's configuration or risk that any future changes made by programs will set JPG back to its default registry value. What we need to do is create a file that will look like its a JPG (not be the icon, but by the type) and will act like an EXE. but a jpg icon can still be applied also. example: "file.jpg " notice the space after the ".jpg". This is no ordianry space, but a special char that for writing it, you need to do as follows: Get the EXE you want to convert to "jpg". rename it from "file.exe" to "file.jpg". Now press the rename again, and in the end of the .jpg, press the ALT key (dont let go of it) and on the keypad, type "0160" this will look like this: "file.jpg ". you can now rename it to something like "my pic.jpg " Go to: Start -> Run -> RegEdit Right click on the HKEY_CLASSES_ROOT key and New -> Key Call it ".jpg " (the space represants the ALT+0160) Inside it, you will find the (Default) string. Double click on it and write "exefile". Then right click anywhere but on the Default string and New -> String Value Call it "Content Type". and edit it so it will say "application/x-msdownload". Right click on the ".jpg " key and New -> Key Call it "PersistentHandler". Inside it, edit the Default string to "{098f2470-bae0-11cd-b579-08002b30bfeb}" Now every EXE file that will have the ".jpg " type, will be executed like a regular EXE! But only on your computer. Right click on the ".jpg " key and Export. Call it something like "fix.reg" and tell the victim you're sending the "picture" to that its a fix so that windows will be able to open your pic or use your imagination or hide it inside another trusted program. I recommand using an EXE joiner to join a real pic to an EXE file so the user wont suspect anything.

Now everyone here is how they did it