The art of disrespecting AV (and other old-school controls), Part 3

Posted on by

This is the third part of the series (part 1, part 2) which this time is somehow shorter, but it is just an excuse to jot down some notes about the actual engines that AV uses internally.

Many people complain about AV using hashes to detect malware – I would say that AV that detects malware via hashes only should not be even on the market, because it would not survive. Your average AV contains a significant number of engines, and subengines using many algos – many of which are lightning fast. Reducing the discussion about AV internal working to ‘AV uses hashes’ is simply not fair.

Let’s have a look – I use the word ‘engine’ quite loosely here and it does not necessarily help with pure detection-specific logic, but it often facilitates the detection itself – each of these are typically quite serious programmatic efforts that are combined to create the ‘holistic’ coverage – yes, it fails, it contains vulnerabilities like any other software, but take a moment to think about the effort that goes into designing, testing all this clustergoodness:

  • static binary string search
  • binary string with a simple wildcards search
  • binary string with a regex (or regex-like) search
  • multi-pattern search engines that are using lookup tables of any sort/trees/tries and proprietary algorithms
  • container/archiver processor – reads files or streams embedded inside the other files/containers
  • file/specific content analyzer/processor – for each file type, content type there is a dedicated engine f.ex. MBR, old Dos .COM file, Flash, OLE files, Symbian SIS, ISO, etc. – note that many of engine expire due to technologies being no longer in use/popular, but it is _there_
  • unpacker  – decompresses streams of data to present them to other engines
  • emulator – simple state machines with a basic understanding of some opcodes
  • emulator – full-blown emulator with most opcodes supported
  • sandbox – full-blown emulator with support of API & memory
  • hooks – dynamic, for on-access scans
  • heuristics engine
  • whitelisting engine
  • detection engine based on file properties
  • rootkit detection engine
  • native file system parser (for various file systems)
  • memory dumper/file rebuilders
  • online scanner (virustotal-like)
  • behavioral engines
  • reputation engines
  • quarantine engine
  • crc/incremental crc search
  • hash-based search
  • entropy analysis
  • X-rays
  • and finally… removal and repair engine – if none of the above engines impress you… think for a second what effort goes to ensure you can remove a complex polymorphic or metamorphic file virus from a gazillion of files on the system without corrupting the files and crashing the system.

There are probably others which I forgot about, but this is really a lot more than just hashing.

If you talk about AV detection and the only thing you talk about is hash, it is probably because you smoke too much of it… 🙂

Why you should sit and study for CISSP

Posted on by

Almost every day I see people on social media whining about the antivirus or firewall being outdated, not working, etc.

This puzzles me.

Logs of these security controls show these controls work just fine. They detect, block and remove a lot of stuff.

Not everything, but lots of it.

This is how security controls work. They cover lots, but not everything.

The fact 0days are being found in the security software does not change the fact they are offering a huge benefit to any organization that runs an open ecosystem (people can install or run code w/o any restriction). Imagine the world w/o them and the internet and all services delivered via this channel collapse.

I start to think that most of people who complain about security controls don’t really understand their function.

Enter CISSP.

I advocate that every single IT security specialist should study CISSP material. You may sit the exam if you want, or not – who cares – but fundamentally, at least eyeball the material to get familiar with the security concepts presented there.

They are the core concepts.

They tell you that the world is NOT perfect and teach you what expectations you should have towards security controls.

They prepare you to recognize threats and manage risk.

They convert you from a techie frog sitting in a comfortable well of your personal interest and hobby into a professional connected to a real imperfect world where shit happens on regular basis, no matter what you do. It’s all about handling it gracefully.