Spoiler (Click to View)

Spoiler (Click to View)
BlueLoader is advanced botnet with GUI that can hold large amount of bots and execute tasks with simple click. Coded in NET 4.0. Besides the loader(download & execute/update) it also has some additional features: Bot killer, visit website(hidden and visible) and ddos layer 7.

Spoiler (Click to View)
PureMiner is advanced cryptocurrency silent miner with GUI support for many different coins. Coded in .NET 4.0. It can auto decide if connected device could use GPU or CPU. It also has build-in proxy and some additional tasks and features.

Spoiler (Click to View)
PureHVNC is advanced botnet with GUI that enables you to control any computer remotely and invisibly. Through it, you can use he mouse and keyboard in a hidden way, control the destkop, open browsers and other applications in a hidden way. Coded in NET 4.0.

Spoiler (Click to View)

Spoiler (Click to View)
DarkVision is a Windows Remote Administration Tool. It is based on a plugin architecture with memory mapped modules that never touches the disk, which allows for flexible loading of functionality on the remote system. Coded in C++ and ASM.

Spoiler (Click to View)
Babylon is old Remote Administration Tool that was being sold on HF and later it has become free, but not open-source. It has only some basic features such as download and execute, remote destkop, file manager and few more. Coded in C++ and ASM.

(May 13, 2023 07:48 AM)i.Shop Wrote:  Not sure this is the right place to post this but I'll give it a try and hope you will forgive me for this long read 😆

I would like everyone to exercise your mind with me for a little bit and let me take you into "paranoid of being detected" mode:

1. Paranoid number One - Crypted file should be clean by itself
   Considering the tests results from previous posts and considering that this is a crypter comparision thread then I think a even better test could be performed to eliminate some of the "noise" and variance from these current results.
   
   In order to understand this first let's consider this scenario with a focus on botnet software first:
   Coder writes botnet software then distributes this to its fellow users.
   Users take some crypt service to crypt the software.
   They use it for a while, everyone is happy.
   After some time or even at the genesis of the botnet software the coder or the client of this software decides to do a test run to the software without the crypter and launches in the wild his uncrypted but FUD file to some 500-1000 target machines.
   
   Well from the moment the coder/user does that then an invisible chain reaction happens that takes a little time: AV products finds this new file with no reputation whatsoever on machine getting executed and sends this to its cloud scanning servers for further analysis. Cloud scanning reveals nothing then standard procedure for these files are to be sent its fellow AV company AV-analysts employees to manually analyse the files then the analyst makes signatures for this uncrypted FUD file. He also trains his machine learning dataset with this file but this will be put into discussion a little bit later.
   After some time the uncrypted botnet software is being detected by some AV products
   
   After all of this now the users takes the file again crypt it and it's FUD on scantime and runtime starts to fail on some products and that cannot be reverted. It will be like this like forever or until software developer reFUD's the uncrypted software while doing runtime scan checks iterations as many as necessary. Since this is a large code base then there is a huge attack surface for signatures of AV's so the coder will have a lot headache to fix this. But most probably the coder will not bother because it thinks it is crypter's job to do that.
   
   The mistake here is of course that developer or client of the software had to launch this file uncrypted just because it worked 😁 which leads to this irreversible runtime detection which cannot be cleaned with any crypt software/service.
   
   This leaves very few options to fix this like:
   Software developer of the botnet could try to fix runtime detections and make his own crypt and deliver both of them always inseparable from each other
   Or each botnet owner make his own software and be careful to always distribute the file only crypted.
   
   In the end here is what could be done about the crypter in order to see how good it is statistically speaking:
   In order to eliminate the risk that botnet software could be tainted by the previous scenario and most probably is then we should remove botnet software out of the picture for these tests.
   We should be making a dummy payload .exe .bat file that is/was never sent in the wild that has 0 runtime detection or close to that ( that can be done I have tested it myself ) then this file should be crypted with the crypter candidates to see if they are able not to be detected with a dummy file for runtime detection.
   Further test iterations can also be made by downloading a malware archive and throwing some parts of the binary of the well know malware into our payload .data then to .code section in order to specifically tune detection for a certain security product at runtime.
   Also further iteration for tuning file .data and .code section and imports can be made.
   This way I think noise variance is removed from the test results and will show how good a crypter is by itself.
   Normaly the crypt that gives close to 0 runtime detections with the dummy file samples should be our best pick.
   Then botnet software should have not been released into the wild then we are good to go for the lowest detection of a pair of crypt+software.
   
   
2. Paranoind number Two - Machine Learning already knows you at first sight
   Machine Learning(ML) aka Artificial Intelligence(AI) algos have grown very powerful for security products in the last 5 years or so.
   ML algos makes uses of scantime and runtime behavior to gather signals in order to get a picture of how a payload looks or behaves.
   
   Some of the signals are:
   - Static scanning signals like: size of the file, file sections (.data .text or others) presence or size of those sections, file imports, visible strings in the sample file, icons, certificates, others resources etc..
   - Runtime scanning like sensitive API calls, persistence events, network connections or behavior while communicating, files executed or dropped. Sample file name or dropped files name. ( BTW this should not be confused with sandbox analysis )
   - Environmental context while executing a file and or execution chain that follows. Meaning which app launched the sample file. Was it powershell/cmd execution? Was it being launched from explorer? Was it being launched from a browser ? Was it downloaded from a browser as archive then extracted then executed? And so on.. All of this is also logged by the ML engine running on machine side in realtime.
   
   Now basically ML gathers all those signals without knowing what's under the hood of the crypt actually then compiles sort of fingerprint out of all these signals then some security product analyst manually categorize this fingerprint as good/bad then inserts it into ML database on the product.
   By doing this they actually train their ML model to recognize new samples that where never seen before and based on their signal count match they then put a "tag" on that newly seen sample into being good, suspicious or bad. For example if is an upgraded version of a very used good software then is safe to assume is a good sample, or if is a recrypt/upgrade of a bad malware then is safe to assume that this is a bad sample, or sample is a suspicious one.
   
   In case file is suspicious then some AV products employs sandboxing of that launched file while letting it launch on the machine. This of course will put some limitations of that sandboxing such as readonly filesystem as a whole or parts of it. Persistence does not hold in this case.
   A suspicious execution in a sandboxed evnironment which could have be avoided should be considered fault of the crypt.
   Some security products that employs such sandboxing are: Comodo, Kasperksy, Mcafee, Fortinet
   
   Normally ML algos need cloud detection to be enabled in order to work at their full power. Scantime detection services has ML disabled to a considerable degree. That includes services like avcheck and even VirusTotal on some of their AV products.
   Controlled runtime scanning even with cloud scanning enabled does not takes into account the environmental context of the sample execution which has been lost or not provided.
   When context is lost then runtime detections don't happen in controlled scanning environment and crypt developer thinks he won the battle. But actually when there is context then file has higher chances being detected in the wild as well.
   
   Back on the ML training model we see that AV companies has now a very big database collection of those signal fingerprints. While matching this huge DB against a new sample, even a good benign one you might find it surprisingly that some of them could be detected as malware causing false positive detection even if they ain't and this is because some malware can have similar fingerprint to a benign software file and they will tend to match to a high degree.
   This why crypt coder has to find a new recipe for its stub for creating a file fingerprint which by chance dos not cross-interfere with the existing ones in that huge DB.
   This of course create a challenge for crypt coder to come up with new out of the box thinking all of the time in order to succeed.
   The change of file icon for example that has been talked about to optimize file detection is because of that false positive detection of an already made malware that is similar
   Just because some other person out there already used a similar crypt design with similar icon that is why now file is being detected even if has not been spread in the wild yet.
   
   Here is a practical real example of ML into action:
   Nowadays WD on Windowns 11 started to be acting differently that WD on Windows 10 when the same sample file is executed on them.
   WD 11 now has the same detection algos and signatures as WD 10 but WD 11 has now a more aggressive approach when comes to ML detection.
   While creating a undetected file and scanning it and even launching on WD 11 from explorer all could work just fine but after taking it a bit further:
   1. making an archive and put file into archive and download this file from a host you might notice that WD 11 pops that payload is detected compared to just bringing the payload in WD 11 by other means and just executing it.
   2. launching file from a shell script would make WD 11 change its behavior and consider that payload file is actually a malware
   So as you can see its a mixture of how suspicious is a file plus its execution context in order to obtain best results
   
   Now let's sum this up: A crypter is not enough to secure file detection to a maximum. There should be a testing of the whole pairing of: execution chain context + crypt + botnet software
   After establishing the real case scenario of execution context we could then crypt the software and adjust parameters of the crypt and/or botnet software in such a way that ML detection is reduced to a minimum. In such a case good tools like scanner.to cannot control the execution context because is automated. Because of this a crypter coder would have to deploy its whole runtime scanning system for at least the most common security products out there in order to be able to reproduce the exact execution context for each software that is being used with the the crypt.
   Based on some study of mine. Having general audience traffic of installs (that does not includes corporations, just regular people target machines) then usually traffic distribution by AV product as follows: has about 30% WD 10 , about 30% WD 11, about 20% Mcafee, about 5% Avast/AVG. Products which are the most used.
   So at least for these the whole pair of context+crypt+botnet software should be tested and fine tuned on those to obtain the best detection results.
   A crypted software that has pass ML as suspicious should be considered as a failure because sandbox will only offer initial execution of that payload because cannot obtain persistence in any way. Crypter+Software should be refined in such a way that ML suspicion status of the file to be removed
   

To conclude all of this:
I think in order to have best results would be that just one coder to create a monolyth software that has it all-in-one, crypt + botnet software + well tested in the wild against all detections technologies of present, that's the only way to control detection at its best
But we can also accept compromise since the perfect outcome is very hard to achieve involving very hard work from the coder perspective which also tries to make his living out of this.
Bringing a sample file to being clean 60-70% on a real case execution scenario is now achievable but the difference of going from that 60-70% to up to a 100% is getting very harder to do by each additional 1% gained on top of that 60-70%.

We can either be "paranoid of being detected" or just make compromise and accept that shared commercial software has its limitations.

Thank you for reading, please leave a QL or HQ post if you enjoyed it.
Stay tuned for more content.
Sincerely, LEGENDS

Spoiler (Click to View)

Spoiler (Click to View)

(Feb 26, 2023 11:23 AM)Nano Shield Wrote:  just few things to add. I see you did some runtime scan with 6/26 scantime, what's the point of doing that since most detections will be scantime not runtime, checking a 1/26 file for runtime is fine, probably a simple icon change would have fix those high detections, you can notice the 1/26 got the

(Feb 26, 2023 11:23 AM)Nano Shield Wrote:  Also my crypter bypassed WD with the right settings, my customers can confirm.
Also I sell private stubs too not only shared.

(Feb 26, 2023 11:23 AM)Nano Shield Wrote:  Other than that, good job

(Feb 26, 2023 12:02 PM)Azx31 Wrote:  Really interested to see how private stubs perform

(Feb 28, 2023 09:15 AM)MRKTRK Wrote:  Very interesting thread, I'm looking forward to the results.

However, it should be noted, especially for beginners, that the crypt with the least detections is not always the best. I have tested many different crypts from different sellers and at some point I stopped counting with how many I had problems like a low connection rate, not mining bots, not working WD exclusions and more.

Anyway, this thread is good to show people the right way.

(Feb 26, 2023 09:51 AM)scanbuddy Wrote:  -Snip-

(Feb 28, 2023 10:22 AM)Royal ! Wrote:  So you just crypted files using my crypter, then when you have had any detection issue, then you are supposed to contact me for CUSTOMER SUPPORT and get your issue resolved. If am not able to resolve it, then you move on and post these results. But as of now, these results are NOT VALID at all because you NEVER CONTACTED me, At all. I even see in your so called review you said "We couldn't build a working payload and get these products working together". So what did you do about that?. Your FIRST JOB was that if you couldn't get a file working with byte crypter, you contact me and ask me to get it resolved for you, but you did not?.

(Feb 28, 2023 10:22 AM)Royal ! Wrote:  All this time you waited and waited just to post results in this thread?. Seriously?. I smell something fishy here.

(Feb 28, 2023 10:22 AM)Royal ! Wrote:  *@OP, you are NOT a customer of mine.

(Feb 28, 2023 10:22 AM)Royal ! Wrote:  And if you are trying to "sneak in" to produce results, you are doing a clear violation of site policies.

(Feb 28, 2023 10:22 AM)Royal ! Wrote:  Lastly, if you have had posted this thread about some mainstream tools like a remote admin tool, any miner, any other one time "buy and use forever" type product I would have understood the point of this thread.

(Feb 28, 2023 10:22 AM)Royal ! Wrote:  But creating such threads about "crypters" makes no sense whatsoever.

(Feb 28, 2023 10:22 AM)Royal ! Wrote:  So you just crypted files using my crypter, then when you have had any detection issue, then you are supposed to contact me for CUSTOMER SUPPORT and get your issue resolved. If am not able to resolve it, then you move on and post these results. But as of now, these results are NOT VALID at all because you NEVER CONTACTED me, At all.

(Feb 28, 2023 10:22 AM)Royal ! Wrote:  I even see in your so called review you said "We couldn't build a working payload and get these products working together". So what did you do about that?. Your FIRST JOB was that if you couldn't get a file working with byte crypter, you contact me and ask me to get it resolved for you, but you did not?.

(Feb 28, 2023 10:22 AM)Royal ! Wrote:  All this time you waited and waited just to post results in this thread?. Seriously?. I smell something fishy here.

(Feb 28, 2023 10:22 AM)Royal ! Wrote:  Further, this is a TOTALLY POINTLESS thread based on few factors-:

*Crypters often get refuded/updated regularly, and so the detection rate changes. So this thread is based on what?. What is the foundation of this thread?. If one crypter is getting good results one day, does not mean the next day it will be same. And same goes for any "bad result".

(Feb 28, 2023 10:22 AM)Royal ! Wrote:  *Crypter sellers provide customer support to their customers to get their detection issue resolved, if they get detection issues that does not mean the product is "bad" or you are exposing some real "truth" about any product. That means either the crypter is pending REFUD/UPDATE or the Customer is requiring customer support from the seller. Sellers are NOT supposed to keep OP Updated about latest refud scans or results, that again makes this thread pointless.

(Feb 28, 2023 10:22 AM)Royal ! Wrote:  *@OP, you are NOT a customer of mine. And if you are trying to "sneak in" to produce results, you are doing a clear violation of site policies.

(Feb 28, 2023 12:11 PM)Ph4n70M Phr34K Wrote:  This is just a market research as it says.
We own crypter licences, we bought them and reviewed.
We would be happy to review YAK Crypt.

(Feb 28, 2023 12:17 PM)Dyne Wrote:  No disrespect to you, as I acknowledge and respect your previous accolades and accomplishments, however;
Discussion about smart purchase decisions is allowed and should be allowed. Market research and understanding is allowed.

When you purchase an item, do you rely solely on what the listing tells you? or do you look to consumer reviews first?
These users actively purchased licenses to extract a market sample. This is not wrong and should be encouraged.

I bid you good luck in your journeys and hope you have been well.

(Feb 26, 2023 09:51 AM)scanbuddy Wrote:  ScrubCrypt | Contracted customer review

- ScrubCrypt + BlueLoader Botnet | Runtime results ->8/20 | Scantime results ->0/26
Bypassing: Windows Defender, Kaspersky, Malwerbytes, McAfee, Norton

- ScrubCrypt + PureMiner Botnet | Runtime results ->6/20 | Scantime results ->2/26
Bypassing: Windows Defender, Avast, AVG, Kaspersky, Malwerbytes, McAfee, Norton