Saturday, June 9, 2018

Happy birthday to Jeffrey

Jeffrey's birthday was actually over two months ago, but we can still celebrate it today. His real birthday is March 29th.

But what else do you know about Jeffrey's birthday?

Jeffrey was actually supposed to be born in April, but he insisted on coming a couple weeks early.

Tuesday, September 26, 2017

Anti-forensics Thought: Recovery Partition

I was just listening to a speaker talk about disk forensics. He mentioned how we can just skip over the "recovery partition" on the disk we're examining since, "That's not usually interesting to us."

Hmmmmmmmmmmmm.......     Got me thinking.

I wonder if any bad guys have ever tried using that partition as a place to hide bad things?

A quick Google search reveals little speculation or discussion on the topic.

Tuesday, January 31, 2017

Weekly Infosec News Brief


Picture
New Version of Shamoon 2 PC-Destroying Malware Used in Attacks on Organizations in Saudi Arabia
The Shamoon malware family has been seen in the past in attacks on Saudi Aramco, and a variant was used in the attack on Sony Pictures in 2014. This malware is very unusual in that it is designed to attack an infected PC and to destroy not just the data on the PC but also the hard drive itself, rendering the PC essentially unusable by destroying the master boot record. Ransomware has also been repurposed to similar effect recently, simply to render data inaccessible rather than demanding a ransom. These incidents highlight the differing tactics that can be used by attackers with different purposes or goals, and the need to ensure that organizational data is securely backed up on systems otherwise inaccessible from the main network.
http://www.reuters.com/article/us-saudi-cyber-idUSKBN1571ZR
https://www.infosecurity-magazine.com/news/saudi-arabia-issues-shamoon-2-alert/

Gmail to Start Blocking Javascript Attachments
In the ongoing cat-and-mouse game of malware, javascript files have become a popular method of delivering malware attachments in emails, mostly because they are executed by default on common computing platforms and are not blocked by many email systems. The notice states that .js files will be blocked whether attached on their own or inside of a zip file. What file extensions are blocked by your email system? What else are you doing to prevent the accidental execution of undesirable files?
http://computerworld.com/article/3161898/security/gmail-will-block-javascript-attachments-a-common-source-of-malware.html
New York Times and BBC Twitter Accounts Hijacked to Tweet "Fake News"
Last week Twitter accounts belonging to the NY Times and BBC were taken over by hackers and used to tweet false news stories. The group apparently responsible is known as OurMine and has previously taken over the accounts of many prominent figures and organizations, including Twitter's own CEO Jack Dorsey. What would be the fallout if your organization's Twitter account were abused in this way? How does your organization control access to corporate Twitter, Facebook, etc., accounts? Tight tracking of who has access is recommended, along with the strict requirement to use multi-factor authentication on all social media accounts.
https://www.infosecurity-magazine.com/news/ourmine-hacks-new-york-times-to/
http://www.huffingtonpost.co.uk/entry/bbc-northampton-twitter-account-donald-trump_uk_588340fae4b0f94bb303e768
Picture
Mozilla Issues New Firefox Version to Fix 33 Security Issues, Five of Them Critical
Last week Mozilla released a new version of the Firefox browser, Firefox 51. The update fixes five critical vulnerability (as well as some lesser issues), all of which could possibly enable an attacker to trigger code execution via a vulnerable browser. Three of the issues are memory corruption issues which could cause a crash and subsequent execution of attacker-provided code. If you support Firefox in your environment, it is vital to ensure that all installations are updated. Anchor recommends employing the enterprise browser management features of Firefox to ensure your organization can keep Firefox up to date and enforce configuration settings.
https://www.scmagazine.com/mozilla-issues-five-critical-patches-for-firefox-and-firefox-esr/article/633852/

WebEx Browser Plugin Vulnerability Found; Cisco Rolling Out Patches
A very dangerous vulnerability was disclosed last week in Cisco's WebEx browser extension. The vulnerability allows any website to run arbitrary code on a machine with the vulnerable extension installed, if they can get the user to visit their malicious site (typically via spearphishing, etc.) Cisco has an updated extension for Chrome available, and is working on updated extension for IE, Firefox, etc. This is a VERY widely installed browser extension used to enable interactive videoconferencing from your desktop or laptop, so most organizations probably have this installed on a large share of their workstations. Anchor recommends ensuring that the update for Chrome is installed and blocking the WebEx plugin on unpatched workstations. The larger question raised by this issue is, are you monitoring not just the browsers installed in your organization, but also the plugins, extensions, apps, and other add-ons enabled in modern browsers? Do you have the ability to block the use of insecure browser plugins/extensions?
https://arstechnica.com/security/2017/01/ciscos-webex-chrome-plugin-opens-20-million-users-to-drive-by-attacks/
http://www.csoonline.com/article/3162349/security/cisco-starts-patching-critical-flaw-in-webex-browser-extension.html

Friday, March 4, 2016

RSA Talk - “IOCs are Dead - Long Live IOCs!” - Ryan Kazanciyan

RSA Talk - “IOCs are Dead - Long Live IOCs!” - Ryan Kazanciyan

Ryan Kazanciyan, Chief Security Architect, Tanium ( @ryankaz42
Co-Author, Incident Response & Computer Forensics (book website: https://ir3e.com/ )

This talk was delivered 04 March 2016 at the RSA Conference in San Francisco. 

I'm providing a brief reaction/summary, and then my notes. The notes are my sort-of free-form notes, so if they are only semi-comprehensible.

REACTION:
I’ve always been skeptical of the threat intel (really mostly threat data) trend. It’s not a bad idea, but it seems like really just a new analogue to signature-based detection; it can only help detect something that someone else has already detected someplace else.

Ryan shares my concerns with the use of threat data, and gives some other reasons why its use is problematic. Not only is the data by definition incapable of deleting truly NEW threats, but it is inconsistent and often of dubious use even for its intended purpose(s). He gives some good ways to make better use of such data, as well as some methods of scouring your own systems for high-value threat data.

NOTES:
Five years ago, the compiling and sharing of indicators of compromise (IOC) seemed like it would “save the world” from attacks.

Today, this has still not become a reality.

Problems:
  • Brittle indicators with a short shelf life
  • Poor quality of data in IOC feeds
  • hard to build effective home-grown IOCs
  • Tool for ingesting and detecting IOCs are inconsistent in quality
  • IOCs are applied to a limited scope of data

Threat Intelligence is not equivalent to threat data
- Intelligence includes context and analysis
- However, good threat data is required for useful intelligence
- For this talk, we’re just talking about threat data, not intelligence

IOCs are Brittle:
  • IP addresses and malware file hashes are most common
  • URLs/hostnames are next most common
  • File names are another common type
  • 4/5 of malware types last less than a week; 95% less than a month
  • C2 IPs and domains have a short lifespan
  • Shared hosting means malicious sites often share an IP with compromised hosts (leads to false positives)
  • Even paid feeds are not necessarily high quality
  • Informal look at IOCs from paid, subscriber-only feeds
    • File IOCs that include both hash and filename (filename easily changed, will lead to false negatives)
    • File hashes included for files that are unique to a specific host
    • Legitimate software libraries included as malware hashes because they were leveraged in some piece of malware
  • Hard to avoid being too specific (leading to false negatives) or too general (leading to false positives)
  • High-effort IOCs work for a specific investigation, but not for generic use across enterprises

IOC Detection Tools are Inconsistent:
  • Tools support (and don’t support) different observables from standards (OpenIOC, Cybox, STIX, YARA, etc.).
  • Logic structures in IOCs are not always implemented in the same way.
  • Data normalization is a problem.
  • The standards have some issues. E.g., OpenIOC was not created intentionally as a standard, but is merely the XML format created for Mandiant’s MIR tool. This has led to some serious issues.

Broadening the Scope of Endpoint Indicator Usage:
  • Most common host data in SIEMs:
    • AV/anti-malware
    • HIPS logs
    • Event log data, usually for only a subset (e.g. servers)
  • Things like file hashes will therefore simply never be seen in the SIEM.
  • Matching on forensic telemetry data
  • Matching on live endpoints:
    • Gives access to everything in memory, files on disk, and event logs.
    • Can be high-impact and hard to scale.
  • The Goal:
    • Mixture of the above methods to maximize the value of brittle IOCs.
    • Increase cadence of analysis as tools & resources permit.
    • Taking shortcuts in coverage (“I only need to check my most important systems”) will leave gaps and lead to failure.
    • Malicious code and actions rarely take place on the actual target servers.

Shrinking the Detection Gap:
  • The most relevant threat intelligence is what comes from within your own environment.
  • Over time, the effectiveness of looking for known IOCs has decreased.
  • Looking for attacker methodology and outlier files/behaviors has correspondingly become more effective.
  • The reality is that automation using known IOCs/threat data is good at finding the easiest things to find.
  • Preventative controls need to fill a large part of that gap, as does internal analysis.

Looking inward to hunt:
  • Derive intelligence from what is “normal"
  • Build repeatable analysis tasks — a repeatable process
  • More is not always better — start small with high-value indicators
  • “What easily observable outlier conditions do intruder actions create?"

Example of Duqu 2.0 report:
  •  All the various samples created a scheduled task to run an msiexec.exe command.
  • However, the provided IOCs consisted of a long list of file hashes and C2 IPs.

Example of analysis of scheduled tasks:
  • create list of what accounts are used to run scheduled tasks
  • create list of what actions/programs are being run using scheduled tasks
  • Look through this for outliers

"Hunting in the Dark” talk gives more detailed examples. https://speakerdeck.com/ryankaz

Things to check out:

Questions for your threat feed vendor:
  • Where is the data coming from?
    • actual IR engagements
    • honeypots
    • auto-generated sandbox data
    • firewall and other device/system data
  • What is the breakdown of observable types? (IPs vs URLs vs file hashes, etc)
  • What is the QC process? (if there is one!)

RSA Talk - “The Pivot” - Jonathan Trull

RSA Talk - “The Pivot” - Jonathan Trull, VP for Information Security, Optic ( @jonathantrull


This talk was delivered 04 March 2016 at the RSA Conference in San Francisco. 
I'm providing a brief reaction/summary, and then my notes. The notes are my sort-of free-form notes, so if they are only semi-comprehensible.

REACTION:
The idea that we need to move beyond just perimeter protection and do better on detection of and response to ongoing intrusions is a repeated theme in the industry over the past several years. Many organizations are still not really implementing this, though, or implementing it well.

This was a great talk with lots of good practical ideas for defense that are implementable my mid-sized organizations. See the notes for specific technical details, but the key points are:
  • Don’t just go with default logging settings on devices and security tools.
  • Central logging and analysis is key.
  • Develop a strategy of specific indicators to look for to make that central logging and analysis effective.

NOTES:
Attackers’ immediate goal is to exploit and compromise a host.
However, this is not their true goal. They want to get deeper and gain access to your key systems and information.

To do this requires the attacker to move on from that initial compromised host — to pivot.

On average, attackers’ “dwell time” in a victim network is 205 days (2015 numbers from Verizon DBIR).
Organizations are still most frequently made aware of compromises by law enforcement or other contacts from outside the organization.
"We don’t necessarily have to be that good, but we have to be better than this."

60% of attackers are able to compromise an organization within minutes.
75% spread from Victim 0 to Victim 1 within 24 hours.

Time is NOT on Our Side:
  • 50% of users open emails and click on phishing links/attachments within 1 hours.
  • Median time to first click is 1 minute, 22 seconds.
  • Half of CVEs are being actively exploited within a month of their publication.

Optiv Simulated Attack Lifecycle:
- Set up lab environment with nine common types of security software/tools
- Conducted simulated attacks: exploitation, lateral movement, exfiltration
- Monitored tools to see what they were able to do to aid in detection of these attacks

How attackers typically pivot & move laterally in a network:
  • leveraging native tools: cmd.exe, powershell, at.exe, Net use, WMI
    • Difficult to detect, as no software is written when these tools are being used
  • using tools to compromise creds: Mimikatz, WCE

Telltale signs of a pivot:
  • Signs can appear on the source host where the attacker is already operating, on the destination machine that they are trying to access, and on the network between them
  • Unusual use of commands that end-users rarely use: scheduled tasks (at.exe), WMI, PowerShell, RDP
  • nmap and ncat and other similar things occasionally; also sysinternals tools (PSExec, 
  • mapping shares
  • Windows Event Logs
  • Events to look for:
    • Account lockout (4740)
    • User added to privilege group (4728, 4732, 4756)
    • Security-enabled group modification (4735)
    • Successful User Account Login (4624)
    • Failed User Account Login (4625)
    • Account Login with Explicit Credentials (4648)
    • Process Created (4688)
    • Service Being Started (7035/7036)
  • Windows Logon Types:
    • Interactive
    • Network
    • batch (scheduled tasks)
    • Service
    • Unlock
  • Using Process Created Event (4688)
    • documents process, user, and parent process
    • Does NOT include command line arguments (by default)
    • This is disabled by default — can be enabled by Group Policy
      • Computer Configuration > Policies > Windows Settings > Security Settings > Advanced Audit Configuration > Detailed Tracking
    • Enable command line args by Group Policy also
      • Enable via GPO – “Include command line in process creation events”
  • Prefetch Files
    • Good place for forensic analysis to see executable, DLLs called, count of times process has run, most recent run time
    • WinPrefetchView
  • Windows Special Groups
    • Introduced in Windows 7/Windows Server 2008
    • Tracks logons of privileged accounts
    • Event ID 4964
  • Pass the Hash
    • Event ID 4624 (for success; 4625 if failed) - Logon Type 3, Auth Package NTLM
    • Filter: Not a domain logon, not an anonymous logon
  • New Scheduled Tasks
    • Event ID 7035 created by at[#].exe
  • Privilege Escalation
    • Login from one non-workstation host to another non-workstation host
    • Login from one workstation to another
    • Login with service account (or attempt to do so)
    • Creation of new domain admin (or elevation of account)

How to identify/detect the signs and defend against the pivot:
  • 100,000 foot view vs. In the weeds

Optic’s Results on Comparing Seven Common Endpoint Security Solutions:
  • Intentionally unpatched/vulnerable hosts
  • Endpoint security solution was the only defense measure on the host
  • Types:
    • Endpoint Protection Platforms (full suites)
    • Exploitation Mitigation
    • Exploit Detection and Response (EDR) with App Control (whitelisting)
    • EDR without App Control
  • None of the types of controls were silver bullets
  • None blocked most pivot attempts; EDR partially blocked most types
  • Generally they logged the info necessary to detect the pivot, but not clear out-of-the box (required research and testing to find)

Takeaways:
  • Enable sufficient logging
  • Develop a threat model for how an attacker would go after your “crown jewels"
  • Central logging and analysis is key
  • Consider using honeypot(s)
  • Implement enhanced authentication for admins and pass-the-hash mitigation


http://www.secopslabs.com has some results and other details and recommendations 

RSA Talk - “Defense in Depth is Dead; Long Live Depth in Defense" - Matt Alderman

RSA Talk - “Defense in Depth is Dead; Long Live Depth in Defense" - Matt Alderman

Matt Alderman ( @maldermania ) is VP of Strategy at Tenable Network Security.

This talk was delivered 03 March 2016 at the RSA Conference in San Francisco. I'm providing a brief reaction/summary, and then my notes. The notes are my sort-of free-form notes, so if they are only semi-comprehensible.

REACTION:
I’m not convinced this is particularly valuable distinction. The title and terminology makes it sound more radical than it is. The real message appears to be simply that we need to more closely integrate and monitor our defenses, which is unquestionably a good point and a vital strategy.

NOTES:

Defense in depth isn’t helping us tackle the attacks we are facing.

The traditional defense in depth model includes:
  • Prevention
  • Detection
  • Response

We haven’t connected the different solutions at the different security layers, so there are gaps that intruders hide in.
The different solution at the different layers are often managed and owned by different group in the organization.

“It is time to declare that defense in depth is dead; we need a new approach."

The depth in defense model:
  • Visibility
    • Discover - assets (physical & virtual, apps, data, mobile, cloud)
    • Assess - vuln assessment, config audit, malware detection
  • Context
    • Monitor - log collection, activity monitoring, packet inspection, threat intel
    • Analyze - event correlation, anomaly detection, behavioral analysis
  • Action
    • Respond - Notification & alerting, remediation, patch mgmt
    • Protect - path installation, config changes, port/service modification, device isolation

This model provides:
  • Visibility
  • Context
  • Action

How do I get started?
  • Do you have continuous visibility to identify unknown assets/devices?
  • Do you have continuous visibility into the security state of your assets?
  • Do you have critical context to prioritize threats and weaknesses?
  • Do you have critical context to measure security posture & assurance?
  • Are you able to take decisive action to respond to attacks?
  • Are you able to take decisive action to remediate your assets?