Hi Eric,

Here are the links to some malware repos as promised. The malware is in a password protected
zip file for safety reasons. Zip password is the standard “infected” used in the security
community. Be careful! On top of that, you can get malware from an open source repository
such as theZoo (https://github.com/ytisf/theZoo). You can then mutate all your malware
samples into new variants to test anti-malware products against “0day malware”.
https://www.dropbox.com/s/nvi6ggg8y7276po/2018-01-31.zip?dl=1

In any kind of efficacy testing, it’s vital to create and test against new 0day malware samples to
reflect real world conditions. Browsing the web for malicious sites or downloading “recent”
malware is highly unlikely to produce an 0day malware sample due to the short time to live
before it’s added to reputation databases and/or gets a signature. It’s still an interesting test, but
one that I’d recommend complementing the 0day malware test with. A file with just one
character change produces different hash values which breaks reputation lookups. AV vendors
only have so much space for signatures, so it’s amazing how effective this little change can be at
bypassing AV. For many, the extra step of swapping out icons breaks the more brittle signatures
and heuristics (signatures for behaviors in the AV world). You can also take a packer or crypter
that compresses and optionally obfuscates the file and how it unravels in memory to execute.
Few vendors do well against the more common packers. They essentially write code to unpack
the file, but that itself has been a nonstop race like signatures. When that happens during
testing, grab another free packer or a trial copy or even jump on hackforums.net and pay a few
bucks for a criminal underground packer/crypter and get more great results from the attacker
perspective. There are several being advertised and sold on there with forum members leaving
reviews.

If you’re comparing products claiming they do Machine Learning, the efficacy comparison
becomes more about how resilient the math models are which you can determine by the update
frequency as well as testing against 0day malware samples. Mutate old malware families as well
as newer malware for testing since the volume of what’s being “trained” on is a common hurdle
in the practice of machine learning. Vendors new to it will often only train on the most recent
malware because they’re still maturing their data science and how to scale it out. That becomes
a problem since attackers have been using older malware families that have dropped off the
radar. All they have to do in those cases is dodge the reputation lookup by making a change at all
to the malware file to break the hash. It’s all about resilience and being future-proof. It’s why
they refer to math models as being “predictive” in the machine learning world. It’s also
important to test in your production environment on a pilot set of users. That’s when cracks
commonly appear in operationalizing products versus a controlled lab environment with
malware cherry picked by the vendor placed on a gold image with overly aggressive settings that
wouldn’t fly in production. It all goes back to our messaging of “Don’t trust vendors. Don’t even
trust us. Test for yourself.”

It stands out that we excel when you compare math models in those ways applicable to the
machine learning approach. I encourage you to ask any other vendors saying they do ML the
same questions. We update about once, maybe twice a year and most others update every few
days or weeks. We train on malware old and new as a top 10 AWS customer getting multiple
awards, patents, and recognition in the machine learning field. The machine learning approach is
our primary defense mechanism. We aren’t using reputation lookup sources, signatures, or
heuristics because those methods have been in legacy AV for at least a decade, being bypassed
left and right. It’s why we started the company and pioneered the machine learning approach to
AV to begin with and why we’ve grown so fast to 8,000+ customers in less than 3 years of
product availability as a company with no brand recognition to start with. We stand alone with a
huge advantage in that way. The older approaches bog down systems so bad they become
unresponsive which we’re all used to with AV and they’re still the primary defense mechanism
for the other next-gen players. Our impact is unperceivable to the user unless they get curious
about our icon or we block an attack and alert them. One of our largest customers with over
300,000 endpoints pushed out to 130,000 initially and had zero help desk tickets. CPUs love
math.

Many of the other vendors now claiming they’re doing machine learning essentially have 1.0
machine learning math models since they didn’t even think the approach was possible until our
product released and spread like wildfire in the marketplace. That lead we have on machine
learning makes sense because we’re 5 years ahead in terms of R&D with dozens of PhD wielding
data scientists, have somewhere in the realm of 75-90 patents, etc. (Google for Cylance patents).
The new ML implementations you see with the other vendors act as a backstop behind
signatures, reputation lookups, and/or heuristics. It’s because their ML math models are like our
very first beta versions 4-5 years ago before it was practical to implement us in block mode and
dethrone legacy AV. They also have to work around our patents which include applying machine
learning pre-execution. Trying to stop and undo damage watching behaviors doesn’t fly when
you’re dealing with credential and data theft from malware. Again, it’s a huge differentiator for
us. System impact and ineffectiveness remain with them or get worse as a result of still relying
on the outdated protection methods and adding their 1.0 ML engines as another layer. Again,
testing with 0day malware and implementing a pilot is key to getting past confusion and
conflicting messaging from us vendors.

Below are instructions on mutating samples to make 0day malware using a packer/crypter or
flipping a byte and swapping out icons. If you need more help learning how to do these things or
finding more packers and crypters, just hit me up and I’ll jump in to give guidance. You can
google on both of the methods to verify they’re extremely common in the real world.

Simple malware mutation:

By changing one character in the file and replacing the icon with a common, high resolution icon,
it ruins reputation lookups and the more brittle signatures of legacy AV and the least mature
math model. To make the change, open a malware sample in any hex editor and change one
character in the DOS stub header such as, “This program cannot be run in dOS mode” with the
lower case d. Then use a tool such as Resource Hacker
(http://www.angusj.com/resourcehacker/) to change the icon with one from this zip file which
we already use on a regular basis for product
demos: https://www.dropbox.com/s/7lrtkf4zmj41vsr/Icons%20for%20bypassing%20AV.zip?dl=1

Mutating malware with packers and crypters:

If you’d like to use a packer to make your own new malware mutations for testing antimalware
products, below are instructions on using the freely available MPRESS packer. Take any malware
sample and create a new one using mpress.exe which compresses the file and doesn’t even try
to evade AV. MPRESS does a good job against most AV/anti-malware products. A small handful of
antimalware products do a pretty good job of handling MPRESS packed samples, mostly through
unpacking though which is an endless cat and mouse game as explained earlier. In those cases,
just grab a few more packers and crypters to test with. Do the same thing against us to be fair. A
few common crypters used in the commercial world to avoid reverse engineering that you could
also try out are PELock, VMProtect, PESpin, and dotNetSpin. Some more are listed on Wikipedia
under “Executable compression”. Or like I said earlier, you can jump on hackforums.net and buy
something a little more evil. Note the official Cylance ”Test for Yourself” landing page has lots of
excellent resources on lab setup and other tools for making new malware variants. It’s
at http://www.cylance.com/knowthetruth

Making your own malware mutations with MPRESS:

1. Download mpress https://autohotkey.com/mpress/mpress_web.htm
2. Create a copy of the folder containing your malware samples.
3. Copy mpress.exe to that folder.
4. Open a command prompt and change directory to the new malware folder.
5. Run the following command: FORFILES /C “cmd /c mpress –i @file”
6. When it’s done packing all the samples, open the folder and sort by file modification
time so old files are on top. You should be able to delete mpress.exe from the folder and
any samples that failed to pack by deleting the files with older modified timestamps.

For some reason, MPRESS sometimes makes duplicate files. To weed them out and rename files
to match the new file hash:
7. Download and run the portable version of this
tool. http://www.advancedrenamer.com/download
8. Click on the Add Method button on the left pane and choose New Name.
9. Type “<SHA256>.exe” in the box and apply it to name and extension.
10. Click on the Add Method button and choose New Case.
11. Check in the radio button to set lower case and apply it to name and extension.
12. In the right pane, click Add, then choose Directories.
13. Browse to the folder containing the mutated samples.
14. Under the “Name collision rule” dropdown, choose to append an incrementing number.
15. Click the START BATCH button.
16. Open the folder and sort by name. Look for items that end in _1, _2, and so on. Delete
_2 and up so only one copy of the file remains. You might have to do this for a few files.
17. Repeat steps 6 and up to ensure the file set is clean of duplicates.

Note to use Amber (https://pentest.blog/introducing-new-packing-method-first-reflective-pe-

packer/) to bypass some vendors since they added MPRESS packer support. The more packers
and crypters you test with, the better.