This will automatically highlight areas of interest when using the Ghidra decompiler.
This is useful for quickly identifying where a value has or will be used.
4/ Disable print type casting. 🖨️
This removes the (VOID *) (Byte *) etc from the decompiler.
I think this results in a much more readable and python-like experience for new analysts.
(These should eventually be re-enabled when you're more comfortable with Ghidra/C)
5/ Enable the entropy view 🟥
Ghidra has a not-so-obvious feature to display high entropy areas within code.
This can be used to identify sections of data that are encrypted, compressed, or otherwise obfuscated.
6/ Utilise Labels and X-refs. 🏷️
Once you've identified a suspicious area, make sure to check where that area starts, and where it is used.
Using the example above, you can use the entropy view (combined with labels and x-refs) to identify the associated decryption code.
7/ Ignore the data type manager. 🤛
This is a complex feature that is largely irrelevant for those new to Ghidra/RE.
If you're a beginner, I think you can safely ignore it until you're at least comfortable with the Decompiler and other features.
8/ Utilise X-refs from imported Functions/API's. 🕵️♂️
Check where suspicious API's are being used!
Once you've identified suspicious imports.
Make sure you utilise the x-refs (show references to) feature to see where that API is used within the code.
9/ Read the Docs! 📖
When you encounter a windows API, it's useful to read the MSDN docs.
You can then use this information to rename variables and significantly clean up the Ghidra code.
This is a short example to explain the concept.
• • •
Missing some Tweet in this thread? You can try to
force a refresh
[3/23] Once unzipped (pw:infected), load the file into pe-studio for quick analysis. There isn't a lot interesting here, but take note that the file a 64-bit .dll with 4 exported functions.
2/ First, locate a scheduled task containing content that you suspect to be chromeloader malware. Decode the first stage using "From Base64" and "Remove Null Bytes". This will give you the first stage loader in its #decoded form.
3/ Next, check the location of the next stage in the registry. This should be near the beginning of the code.
If you utilise API hashing in your #malware or offensive security tooling. Try rotating your API hashes. This can have a significant impact on #detection rates and improve your chances of remaining undetected by AV/EDR. See below for an example with a Bind Shell vs #Virustotal.
Since API hashing can be confusing, most attackers won't rotate their hashes with each iteration of malware. Those same hashes can be a reliable detection mechanism if you can recognize them in code.
Luckily finding these hashes isn't too difficult, just look for random hex values prior to a "call rbp".
If you're unsure whether the value is an API hash, just google it and see if you get any hits. Most of the time, identification can be a simple google search away.