Category Archives: Incident Response

The comprehensive list of IR sources and alerts (work in progress)

Posted on by

Having security controls in place is a win only if we can leverage these controls to deliver alerts to us. Once delivered we can classify them as noise, events, near-misses and incidents, and … take it from there.

In today’s post I am making an attempt to create a comprehensive list of alerts that one can retrieve from the various security controls.

This is work in progress. If you find something stupid or missing please send comments via email/twitter and I will amend the list. Thanks.

Note: these are potential sources of alerts; classification, prioritization, severity, etc. is not the scope of this list although I add a lot of examples/hints (all these that are specifically named).

This is because:

  • you need to know which controls are available first
  • then you need to look at the raw data they collect i.e. take a snapshot and analyze it
  • and only then use logic applicable to your organization to determine how to work this huge amount of data

I also do not mention how these alerts need to be set up – whether it is via SIEM, Splunk, manual analysis – it doesn’t matter. Treat is more as a bunch of ideas to cherry-pick from than an ultimate guideline how to secure your org. It’s your job after all 🙂

Here it goes…

  • Antivirus software
    • this is IMHO still one of the most important security controls to look at
    • if you don’t handle these as a minimum, you are doing it wrong
    • what helps is analysis of all threats ever detected by creating a matrix representing threat taxonomy and then defining priorities f.ex.
      • alerts from C-level, Senior Management, sysadmins, CERT group, internal pentesting team, and other privileged groups
      • rootkits, known infostealers, hacking tools, etc.,
      • plus alerts from drive C: (indicating infection)
        – all of these are top priority
      • PUA/PUP/adware, stuff on removable devices go at the end, but should not be discarded
      • you can create exclusions/filters for eicar, etc.
    • doing analysis of historical data of AV alerts is very useful; you can immediately spot heavy offenders and try to work with their managers to change the employees’ habits, or business process (f.ex. someone bringing CD/USB from the vendor and sticking it into a production box w/o checking for malware)
    • get to know the AV names that your AV vendor uses for threats of primary interest (even though these will often be very inconsistent)
    • recurring infections on the same system
    • same infections on various systems (potential worm, spam campaign/carpet bombing, outbreak of any sort)
    • prioritize systems where malware was detected, but not removed, especially on C: drive
    • do not forget that detected and removed malware is not equal eradication; imagine a dropper that drops 2 files – one detected and removed by AV, one unknown piece and happily running on the system
  • EDR software
    • this is emerging class of alerts, this pretty much tells you sth is wrong immediately
  • Other HIPS software
  • Whitelisting software
  • Data loss prevention software
  • DNS requests
    • log all of these and keep the history
  • Honeypots
  • FIM (File Integrity Monitors) – tools that ensure no unauthorized file is created or executed on the system (f.ex. Bit9, Solidcore)
  • Network Intrusion Detection systems
    • ‘First Time Seen’ logic bubbles uncommon events up (any signature seen in the previous day but not seen for the n days prior)
  • Firewall logs
  • DHCP logs
  • Unix logs
    • syslog
    • auth
    • …
  • Proxy logs
    • since this is a huge amount of data, review categorization used by vendors; look at all malicious, suspicious traffic
    • do not forget questionable traffic f.ex. porn, warez sites, access to public proxies that may indicate the user wants to bypass controls, etc.
    • also include access to web sites that provide code snippets and programming modules; this is a tough one, especially in a development environment and with ‘stack overflow’ effect where people download and execute quite blindly lots of snippets of code
    • traffic related to IMs; many ppl install unapproved IM clients
    • Tor traffic
    • pay special attention to (often abused) dynamic dns domains (find or build a list; it will never be complete, but it will be worthwhile)
    • pay special attention to “uncategorized” sites if your vendor offers categorization
    • proxy-bypass traffic f.ex. glype
  • Web Application Firewall (WAF) logs
  • Content Filtering software
  • Server logs
    • From various servers
      • IIS
      • Apache
      • Nginx
    • Server Web Requests
      • can prioritize file uploads, keywords detected in queries, unusual IPs
      • can whitelist internal pentesting teams boxes, known external vulnerability scanners [external vendors running scans on your systems]
  • Client Web Requests [mainly browser requests, but can be also self-updates, etc.]
    • GET on .exe files (it may sound overwhelming at first, but worth at least analysing it)
    • GET on all archive file types (f.ex. zip, rar, 7z, tar.gz, bzip2, etc.)
    • GET on .pdf files
    • GET on .swf files
    • GET on .jar files
    • GET on .class files
    • Large POST requests (suggesting uploads/exfiltration)
    • Long duration POST requests
    • Large number of requests to the same address
    • Frequent POST requests (f.ex. 1/hour) to the same address
    • Requests that end up with HTTP errors (these may help to find new drive-by patterns, phishing campaigns)
    • Unusual User Agents
    • Access to file hosting portals
      • Dropbox
      • Box
      • Google Drive
      • OneDrive
      • Internal / External solutions for sharing data with customers/internally
      • …
    • Access to sensitive systems
      • HR
      • Payroll
      • Databases
      • Backups
      • …
  • Business-specific systems
    • Ticketing systems
    • Systems within the scope of PCI DSS
    • Systems processing regular data dump exchanges (f.ex. between client and vendor, conversion of data between two different database systems, etc.)
    • …
  • Logs from Custom applications
    • May require enabling of logging/debug logs
  • Successful and unsuccessful logon attempts from any system offering logs really
    • SSH
    • VPN
    • (S)FTP
    • Remote access tools
      • RDP
      • pcAnywhere
      • LogMeIn
      • gotomypc
      • TeamViewer
      • vnc (including various clones)
    • Databases
      • MSSQL
      • Oracle
      • etc.
    • Outlook Web Access
    • Employee Support Pages
  • Email server
    • Emails with subjects including commonly used social engineering keywords
      • dhl
      • fedex
      • paypal
      • …
    • All URLs extracted from emails
    • Potentially other metadata
  • Domain Controllers/Windows Event Logs
    • AppLocker logs (in a comment I received the adviser suggested that it is even better malware detector than AV – provided it is configured properly)
    • Creation of user accounts
    • Adding systems to the domain
    • Creation of services associated with remote execution
      • psexec (psexesvc.exe)
    • Creation of all services (analysis may help to whitelist most)
    • Execution of programs (requires sysmon installed)
    • Successful and Unsuccessful Logons
  • Physical controls
    • any access controls (proximity cards, etc.)
  • Systems used for issuing security tokens
  • Local wi-fi access points
  • Mobile phones
  • Other security controls and asset inventory tools
    • SCCM
      • Regular ‘sweeps’ for presence of
        • single-character and two-character executable file names (p.exe, cc.exe, etc.)
        • executable files including keywords:
          • crack
          • warez
          • keygen
          • hack
          • porn
          • …
        • Tor
          • tor.exe
          • vidalia.exe
        • Portable applications
          • typically used to bypass/hide installation
        • Commonly used command line versions of archivers
          • rar.exe
          • 7z.exe
          • pkzip.exe
          • winrar.exe
        • Commonly used tools for hacking
          • nmap.exe
          • psexec.exe
          • mimikatz.exe
          • pwdump.exe
        • P2P applications
          • utorrent.exe
    • LanDesk instances

Thank you to everyone who helped to expand this list. Much appreciated!!!

Why PUA/PUP are bad for you a.k.a. the evil of environment fingerprinting

Posted on by

In my post about sample targeting EDR I mentioned that the sample is a PUA/PUP. Looking at the code of many PUA/PUP/adware samples created in last few years it’s easy to see how far they go nowadays in fingerprinting the environments.

This is why many of them should be treated as malware & should not be ignored in ‘business as usual’ IR activities.

In the aforementioned post I listed a couple of routine names that that particular sample used. All these routines are called one by one, and a final string is generated containing reference numbers associated with each ‘discovered’ piece in the environment.

fingerprintingThis is no longer just a sandbox detection.

EDR, VPN, AV, security tools, often list of updates, hotfixes, full software list from registry, etc. is added too. Someone, somewhere populates some large databases with a lot of this ‘goodness’.

One can imagine that this data may be a very valuable piece of information – it could be sold not only to advertisers, software writers, even companies whose products are being profiled (competition/market research), but also – of course – on a darker side – to random malware authors, and guys specializing in targeted attacks. If you think of it, a good PUP/PUA campaign could be even orchestrated by the actual BAD guys.

If 0days allow a way in, a database with an information about used software may simplify and speed up a lateral movement. And why bother doing all the time-consuming illegal hacking/malware infestation/recon if you can simply deploy borderline software first. Let it populate a huge matrix including lots of information about as many hosts as possible in as many organizations as possible. And then, with such precise information about installed software & deployed countermeasures it can be leveraged to simplify many hacking operations (and targeting).

This is of course scaremongering on my side and a conspiracy theory in the making, but the only reason I am writing this is that if you are ever looking for arguments to treat PUA/PUP as malware… or someone argues that PUA/PUP can be ignored in your AV alerts then the massive fingerprinting they do nowadays is the big one…