You are browsing the archive for Preaching.

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

December 3, 2013 in Compromise Detection, Forensic Analysis, Malware Analysis, Preaching


Thanks to Kurt Wismer for pointing out a mistake re: false vs. true negatives; I have corrected it below

Old post

Every once in a while I hear people whining commenting about antivirus solutions:

  • “It’s outdated”.
  • “It’s a resource hog”.
  • “Let’s get rid of it”.
  • “It didn’t detect the malware XYZ.”

I sometimes do it too, but… I would never ever remove AV from the company environment. It’s easy to say AV is no longer necessary, or ‘doesn’t work’ . It’s also very tempting to apply one’s localized context of their (often smaller) environment to pretty much every possible situation, but… it just doesn’t work this way.

Let the preaching begin.

What is an antivirus and its role in your environment?

Putting sales BS away, one can say that:

The antivirus’ role in your environment is to:

  • detect known malware using specific patterns/signatures, algorithms, etc.
  • detect unknown malware using heuristics (wildcard/regular expressions, behavioral analysis, file reputation, etc.)

and block/remove it

The ‘known malware’ is an easy bit. You know it, you block it (or kill it).

The ‘unknown malware’ bit is often the major reason for whining, but we should all know that AV is not a ‘cure it all’ solution and there is no algorithm in the world that will allow to detect every single malware. Nearly 30 years ago Fred Cohen prove that detection of viruses is undecidable. The proof will probably make you scratch your head a little, but the beauty here is in its simplicity.

To catch up with the reality, we can expand our definition and say:

The antivirus’ role in your environment is to:

  • detect known malware using specific patterns/signatures, algorithms, etc.
  • detect unknown malware using heuristics (wildcard/regular expressions, behavioral analysis, file reputation, etc.) with the highest possible rate, but with NO expectation of detecting every single malware out there

and block/remove it

Statement like this is far more realistic – people who support this are at least aware of AV weaknesses.

Still, such statement omits one yet very important bit.

The antivirus role in your environment is also NOT to detect non-malicious files.

Ever heard of False Positives?

The availability heuristic makes a lot of people talking critically about AV to focus on the following:

  • False Negatives (malware is missed)
  • False Positives (good file is incorrectly detected as malware).

followed by the obvious:

  • True Positives (malware is detected)

What about True Negatives?

The number of these is tremendous. The thing is, they are NOT reported.

You probably chuckle now. How can we even take it into consideration? After all, we are not paying AV for NOT detecting stuff!

You see, with a decent AV on your system every single operation you do one way or another triggers a background AV check. And it is a far more complex task NOT to trigger on stuff, than to trigger on a very specific pattern. This is especially true for heuristic detections. And this is not to justify AV missing stuff by saying ‘but it’s not detecting the good stuff’. It is just a picture is not full without this bit. If it doesn’t make sense – think of all the posters in Las Vegas showing the casino winners. And then try imagining what would happen if they put the posters of all the losers as well. This is an error of availability at work.

So far we have got:

The antivirus role in your environment is to:

  • detect known malware using specific patterns/signatures, algorithms, etc.
  • detect unknown malware using heuristics (wildcard/regular expressions, behavioral analysis, file reputation, etc.) with the highest possible rate, but with NO expectation of detecting every single malware out there

and block/remove it. The antivirus role in your environment is also NOT to detect non-malicious files.

I guess that’s it.

On a high-level, AV is just one of available security controls that is imperfect by its nature. Interestingly, individual malware detection kinda lost its ‘whoaw’ impact over the years. Malware detections are quoted in groups of hundreds, thousands, and more – and reported in ‘spikes’ on monthly basis. So, right there, in front of our very own eyes we have a proof of AV actually working, and working very well, yet a few missed detections occupy our mind enough to dismiss the benefits of using it. It is true that even a single malware NOT detected can be a game over, but the alternative cost of NOT having AV installed means the chances for game over increase dramatically as its multiplied by hundreds, thousands detection for your average mid-size to large company.

Let’s say it one more time: any single piece of malware that AV detects makes your company more secure.

And about all these neglected hundreds, thousands and more detection reported on monthly basis?

Don’t just stare at the charts. Use it.

In my recent post I mentioned SCCM. AV logs from across the whole company are very useful in finding patterns of malicious campaigns, characteristic patterns, and so on and so forth. The infamous ‘invoice’, ‘fedex’, ‘ups’, campaigns often end up with malware being deployed in a very similar fashion. With such internal intel that can be very quickly pulled from any enterprise-level AV product, it’s very easy to combine it with SCCM and other controls to form a solid detection ‘umbrella’.

The list below shows a few things you can do with AV logs alone:

  • run statistics – pick up systems that are infected over and over again, investigate
  • find systems with detections coming from removable devices – block access to removable devices for repeating ‘offenders’
  • find systems with recurring detections – request rebuild/forensics if you see malware being picked up on the same system many times; AV may be struggling to remove it
  • find systems infected with a highly sophisticated malware (ZeroAccess, rootkits, etc.) – request rebuild/forensics
  • find file names / patterns of detected malware – use it in SCCM queries
  • eyeball the ‘detected & removed’ alerts – most of people ignore the ‘detected & removed’ – once in a while you will find hacking tools, password/information stealers, etc. – these systems are the ones you should be looking at; there may be something juicy stolen from these systems; request credentials changes; these systems may be also compromised by other malware
  • correlate alerts looking at the host names and cross-reference them with a list of important systems – domain controllers, web servers, systems that belong to C-level guys, admins, etc. – anything that processes sensitive data / is a part of a highly critical infrastructure is of an interest
  • cherry-pick systems, fetch samples from Quarantine, run them via sandboxes

The list can go and on.

I would argue that lots of conversations about threat intel, security analytics, clustering, etc. often miss the basic fact that the ‘old-school’ enterprise products provide both data and tools to run lots of correlations and they do it ‘natively’ without any need for BIG DATA solutions or external input.

You heard it right. You can do IR work w/o buying new security controls!

In fact, if you have an AV, proxy/firewall and DNS logs as well as SCCM access you have at your hands most of the data needed to discover a compromise, or a malicious infection. SCCM and AV helps with host analysis, proxy/firewall and DNS with network analysis.The early daily stats can be done with Excel, grep and a bit of scripting. This can be always automated later.

Preaching ends here :)

Finding Smoking Gun and going beyond that – Helpful Forensic Artifacts

August 23, 2012 in Compromise Detection, Forensic Analysis, Malware Analysis, Preaching, Tips & Tricks

While I am quite critical about the idea of collecting IOCs (Indicator of Compromise) describing various malware, traces of hacking, etc in a form of hashes, even fuzzy hashes, file names, sizes, etc., etc.  I do believe that there is a certain number of IOCs (or as I call them: HFA –  Helpful Forensic Artifact – as they are not necessary relevant to compromise itself) that are universal and worth collecting. I am talking about artifacts that are common to malware functionality and offensive activities on the system in general as well as any other artifact that may help both attackers and… in investigation (thanks to ‘helpful’ users that leave unencrypted credentials in text files, watch movies on critical systems, etc.).

In this post, I will provide some practical examples of what I mean by that.

Before I kick it off, just a quick reminder – the reasons why I am critical about bloated IOC databases is that they have a very limited applicability in a general sense; and the limitations come as a result of various techniques used by malware authors, offensive teams, etc. including, but not limited to:

  • metamorphism
  • randomization
  • encryption
  • data (e.g. strings) build on the fly (instead of hardcoding)
  • shellcode-like payloads
  • fast-flux
  • P2P
  • covert channels
  • etc.

Notably, antivirus detections of very advanced, metamorphic malware rely on state machines not strings and it’s naive to assume that collecting file names like sdra64.exe is going to save the day…


If we talk about good, interesting HFAs I think of things that:

  • are very often used in malware because of a simple fact they need to be there (dropping files, autostart, etc.)
  • traces of activities that must be carried on the compromised system (recon, downloading toolchests, etc.)
  • also (notably) traces of user activity that support attacker’s work (e.g. a file password.txt is not an IOC, but it’s HFA)
  • traces of system being affected in a negative way e.g. if system has been compromised previously by a generic malware, certain settings could have been changed (e.g. disabled tracing, blocked Task Manager, etc.); they are IOCs in a generic sense, but not really relevant to the actually investigated compromise; you can think of it of these aspects of system security that place the system on the opposite side to the properly secured and hardened box; it also included previously detected/removed malware – imho AV logs are not ‘clear’ IOCs as long as they relate to the event that is not related to investigated compromise

If we talk about a typical random malware, it’s usually stupidly written, using snippets copied&pasted from many sources on the internet. The authors are lazy and don’t even bother to encrypt strings, so detection is really easy. You can grep the file or a memory dump of a suspected process for typical autorun strings with strings, BinText, HexDive and most of the time you will find the smoking gun. If the attacker is advanced, all you will deal with is a blob of binary data that has no visible trace of being malicious unless disassembled – that is, a relocation independent, shellcode-like piece of mixed code/data in a metamorphic form that doesn’t require all the fuss of inline DLL/EXE loading, but it’s just a pure piece of code. It’s actually simple to write with a basic knowledge of assembly language and knowledge of OS internals. I honestly don’t know how to detect such malware in a generic way. I do believe that’s where the future of advanced malware is though (apart from going mobile). And I chuckle when I see malware that is 20MB in size (no matter how advanced the functionality).

When we talk about IOC/HFAs and offensive security practices, it is worth mentioning that we need to follow the mind process of an attacker. Let me give you an example. Assuming that the attacker gets on the system. What things s/he can do? If the malware is already there, it’s easy as the functionality is out there and can be leveraged, malicious payload updated and attacker can do anything that the actual payload is programmed to do and within the boundaries of what environment where it runs permits. On the other hand, if it is an attack that comes through a typical hacking attempt, the situation is different. In fact, the attacker is very limited when it comes to available tools/functionality and often has to leverage existing OS tools. This means exactly what it says – attacker operates in a minimalistic environment and is going to use any possible tool available on OS to his/her benefit. If we talk about Windows system, it can be

  • net.exe (and also net1.exe)
  • telnet.exe
  • ftp.exe

but also

  • cmd.exe
  • debug.exe
  • makecab.exe
  • diantz.exe
  • netsh.exe
  • netstat.exe
  • route.exe
  • hostname.exe
  • sc.exe
  • arp.exe
  • shutdown.exe
  • findstr.exe
  • at.exe
  • attrib.exe
  • cacls.exe
  • xcacls.exe
  • ping.exe
  • tracert.exe
  • runas.exe

and OS commands

  • echo
  • type
  • dir
  • md/mkdir
  • systeminfo

and many other command line tools and commands.

So, if you analyze memory dump from a Windows system, it’s good to search for presence of a file name associated with built-in windows utilities and look at the context i.e. surrounding memory region to see what can be possibly the reason of it being there (cmd.exe /c being the most common I guess).

Back to the original reason of this post – since I wanted to provide some real/practical examples of HFAs that one can utilize to analyze hosts, let me start with a simple classification by functionality/purpose:

  • information gathering
    • net.exe
    • net1.exe
    • psexec.exe/psexesvc.exe
    • dsquery.exe
    • arp.exe
    • traces of shell being used (cmd.exe /c)
    • passwords.txt, password.txt, pass.txt, etc.
  • data collection
    • type of files storing collected data
      • possibly password protected archives
      • encrypted data (e..g credit cards/track data)
    • various 3rd party tools to archive data:
      • rar, 7z, pkzip, tar, arj, lha, kgb, xz, etc.
    • OS-based tools
      • compress.exe
      • makecab.exe
      • iexpress.exe
      • diantz.exe
    • type of collected data
      • screen captures often saved as .jpg (small size)
      • screen captures file names often include date
      • keystroke names and their variants
        • PgDn, [PgDn],{PgDn}
        • VK_NEXT
        • PageDown, [PageDown] {PageDown}
      • timestamps (note that there are regional settings)
      • predictable Windows titles
        • [ C:\WINDOWS\system32\notepad.exe ]
        • [ C:\WINDOWS\system32\calc.exe ]
        • [ - Windows Internet Explorer]
        • [Google - Windows Internet Explorer]
        • [InPrivate – Windows Internet Explorer – [InPrivate]]
      • possible excluded window class names
        • msctls_progress32
        • SysTabControl32
        • SysTreeView32
      • content of the address bar
      • attractive data for attackers
        • regexes for PII (searching for names/dictionary/, states, countries, phone numbers, etc. may help)
        • anything that matches Luhn algorithm (credit cards)
      • input field names from web pages and related to intercepted/recognized credentials
        • user
        • username
        • password
        • pin
      • predictable user-generated content
        • internet searches
        • chats (acronymes, swearwords, smileys, etc.)
  • data exfiltration
    • who
      • username/passwords
    • how
      • ftp client (ftp.exe, far.exe, etc.)
      • browser (POSTs, more advanced: GETs)
      • DNS requests
      • USB stick
      • burnt CD
      • printer
    • how
      • just in time (frequent network connection)
      • ‘coming back’ to the system
    • configuration
      • file
      • registry
      • uses GUI (lots of good keywords!)
    • where to:
      • URLs
      • FTP server names
      • SMTP servers
      • mapped drives (\\foo\c$)
      • mapped remote paths (e.g. \\tsclient)
  • malicious code
    • any .exe/.zip in TEMP/APPLICATION DATA subfolders
    • processes that have a low editing distance between their names and known system processes (e.g. lsass.exe vs. lsas.exe)
    • processes that use known system processes but start from a different path
    • areas of memory containing “islands” with raw addresses of APIs typically used by malware e.g. CreateRemoteThread, WriteProcessMemory, wininet functions
  • mistakes
    • Event logs
    • AV logs/quarantine files
    • leftovers (files, etc.)

Many of these HFAs form a very managable set that when put together can be applied to different data sets (file names, file paths, file content, registry settings, memory content, process dumps, etc.).

In other words – instead of chasing after a sample/family/hacking group-specific stuff, we look for traces of all these things that make a malware – malware, a weak system – weak, a hack – hack and attack-supporting user – victim.