You are browsing the archive for Uncategorized.

The Hour Between Dog and Wolf

January 1, 2020 in EDR, Mitre Att&ck, Off-topic, Preaching, Uncategorized

10-15 years ago DFIR / EDR / Threat Hunting were not even a ‘thing’. Apart from law enforcement efforts, and a few consulting companies… there were literally no companies doing this sort of work, and even if they actually did… their focus was primarily on QIRA/QFI (today’s PFI) aka analyzing carding breaches, or analyzing APT attacks targeting US gov and defense contractors.

At that time my big wishful thinking was that if I had at least a snapshot of volatile logs from the system I wanted to analyze I would be already better off as opposed to if I had to look at the content of the HDD image alone.

Many in this field of course agreed, and even more, often led us all by an example, so in the years that followed we went through iterations of different solutions… from basic volatile data acquisition batch/bash scripts, memory acquisition tools, then memory dumpers supported by parsing scripts, and we finally ended up with EDR solutions that feed our log just-in-time and fulfill our needs very well today.

Are we better off tho?

I am wondering…

The emergence of EDR evasions, living of the land techniques, static EDR rule breakers, reemergence of macromalware, new code injection techniques, powershell obfuscations, supported by exploits, fileless attacks, code signed with stolen certificates, supply chain attacks, etc. makes me believe that… EDR is going to be for a host what IDS/IPS ended up being for a network.

At first all we got power drunk with firewall/IDS/IPS/proxy capabilities… few years later though many companies literally ignore alerts from these systems as they generate too much noise.

I see a similar trend with EDR.

By comparison… we are very used to AV generating many alerts (especially when AV is configured in a paranoid and/or ‘heuristic’ and/or reputation-check state), but AV itself is still a pretty high-fidelity business. And we often ignore AV alerts that are lower fidelity.

When EDR joined the alerting battleground we at first thought it is going to add a lot of value. After the few years of experience now we face the very same alert fatigue as we experienced with firewalls, IDS, IPS, AV, and proxy. Same old, same old. Just a different marketing spiel.

Along came Threat Hunting… a discipline that is hard to define, but it somehow got its foundation solidly embedded in many companies thanks to Mitre Att&ck Framework. Today’s definition of Threat Hunting is pretty much ‘the act of Mitre Att&ck implementation in your org’. It is actually far more serious than it sounds because it is far more difficult than many people feel. You get to implement a lot of detection in your own environment. One that almost by definition is poorly managed, doesn’t have a proper asset inventory and enforcement of rules is hard. It’s fu, but it’s VERY tough in practice. Yes, in practice, we walk through all the known Mitre tactics and techniques, we cross-reference them with our own org threat modelling/log situation and then come up with new alerts/dashboards that help us to cherry-pick the bad stuff…. hah… very easy.. it it not…

So…

Now we have tones of alerts from ‘high-fidelity’ alert sources: AV, IDS/IPS, proxy, WAF. Then we have middle/low level fidelity alerts from EDR/AV/IDS/IPS/WAF/proxy. Then we have very FP-prone alerts / dashboards from Threat Hunting activities.

What is next?

I do believe it’s time to go deeper and trace user’s activity on a spyware level. Ouch. Yes. I said it. It’s a very difficult topic from a legal perspective, but imho it’s the only way to link user’s actions to actual events we see on our blinkenlight boxes. If we can establish a solid link between user clicking certain GUI elements, typing certain commands, credentials, etc. it’s only then we can be sure that we can provide a context for events we observe in our logs. I mean.. seriously… if we need to spend a lot of resources trying to link multiple Windows Event Logs together to narrow down activity that could be easily tracked to actual user’s behavior.. then why not doing it the opposite way? Follow the user’s behavior and track it high-level.

It’s not the first time I refer to this topic, but I guess it finally has to be said: you can’t fully monitor the box if you don’t monitor its users activities _fully_.

Welcome to the world of next-gen, panopticon EDR solutions of tomorrow.

And for the record… take any advanced OCR/ICR dictionary software, desktop enhancer, IME, accessibility suite, etc and then you realize that at least for the Windows platform, problem of tracking/monitoring of UI and the data flow as well as user interaction is already solved. Did I mention existing spyware solution used in the Enterprise environment? EDR can be cool, but will never be as cool as a proper keylogger…

Time to hook more APIs EDR vendors…

I’M SO excited, Part 2

October 5, 2019 in Archaeology, Uncategorized, Undocumented Windows Internals

In my last post I touched on some basic mso.dll findings. Today we will continue with the same theme, but instead of exported functions, we will focus on low hanging fruits which are… yup, strings. And I don’t mean your usual dump of all strings from a binary (imagine what value you can get from strings ran over a 26MB DLL), but more focused and API-centric strings.

What is the value?

Knowing unique strings used by APIs can help us to narrow down some interesting functionality/features that may be undocumented, or otherwise useful. In my experience, many of these are good starting points for deeper research that culminates in new posts on this blog, or my better understanding of windows internals.

Let’s take Windows Properties for starters. Some of them can be used to code-inject. This offensive train of thought led me to ask a question: does MS Office offer any window properties that allow pointer overwrites? If it does, it is definitely interesting.

I have identified the following Windows Properties set by MSO.DLL:

  • AirSpace::LayerHost
  • AirSpace::FlipModel
  • AirSpace::IsOverlayWindow
  • MSO_UXHWNDEFFECTSMANAGER_WINDOW_PROP
  • NUINativeHWNDHost

I know there are more, but they need to be identified either via sandboxing, or better static analysis. I also didn’t identify any that allow pointer overwrites yet, but at least we have our foot in the doors.

There is also a list of atoms mso.dll creates:

  • VertLine
  • HorizSlider
  • ListColumnLabel
  • ColorAreaImage
  • ColorSwatchButtonContainer
  • GroupHeaderContainer
  • ColorSwatchElement
  • ScrollViewer
  • PanViewerScrollButton
  • ButtonDropArrow
  • TreeViewContentImage
  • TreeViewContentLabel
  • TreeViewContents
  • ListViewViewer

At the moment I don’t see any use for these, but again, the more strings you recognize, the less time you need to spend on them in a future & can also use them in exclusions of any sort (e.g. yara strings or code markups).

Another bit that is easy to spot are RichEdit Classes. I used to think I know them all, but mso.dll surprises us again. Here is a list of Window classes mso.dll recognizes:

  • RichEdit20A
  • RichEdit20W
  • RichEdit20WPT
  • RichEdit50W
  • RichEdit60W

Another interesting bits I found are some of the environment variables expected by mso.dll; among these common ones that everyone recognizes we can also see these two weird ones:

  • LORI_099F5E083DF84BC98E90139DFB45C0B9
  • msooaopt

Again, I have no idea what they represent at the moment, but it’s yet another research bit we should pursue.

Okay, now that we had a quick glance over exported functions that are directly mapped to Windows APIs, and unique strings that are easy to include/exclude, we should go a step further.

What about file names or anything that uses a file-extension-like strings e.g. MIME types or Object names?

A quick regexp reveals the following strings of interest:

  • Access.Application
  • AccessAddin.DC
  • AssetLibrary.ico
  • blog_request.xml
  • blog_response.xml
  • client_LocationBasedDefaults.html
  • communicator.ex
  • CompositorFrames.csv
  • ContactPicture.jpg
  • CorelPhotoHouse.Document
  • CsiVersionSupportsSecureHttpRedirection
  • customStreamsXsn.xml
  • DataContext.Label
  • DataSource.Anchor
  • DataSource.CanGrow
  • DataSource.Categories
  • DataSource.Commands
  • DataSource.EventingItem
  • DataSource.FilterIndex
  • DataSource.FilterItems
  • DataSource.HelpId
  • DataSource.HighlightedItem
  • DataSource.HighlightedValue
  • DataSource.ImageSource
  • DataSource.InRibbonItemsHeight
  • DataSource.InRibbonItemsWidth
  • DataSource.IsAnchorEnabled
  • DataSource.IsAnchorPressed
  • DataSource.IsAutoCompleteEnabled
  • DataSource.IsBitFiltering
  • DataSource.IsDropFullWidthEnabled
  • DataSource.IsDropped
  • DataSource.IsFilterVisible
  • DataSource.IsScrollToSelectedEnabled
  • DataSource.IsSelectionRequired
  • DataSource.Items
  • DataSource.ItemsHeight
  • DataSource.ItemsWidth
  • DataSource.Label
  • DataSource.Layout
  • DataSource.ResizeType
  • DataSource.SelectedItem
  • DataSource.SelectedString
  • DataSource.SelectedValue
  • DataSource.StatusText
  • DataSource.SuperTip
  • DataSource.Tooltip
  • DocumentRepository.ico
  • EasyPhoto.Photograph
  • editdata.mso
  • Excel.Application
  • ExcelPlugInShell.PowerMapConnect
  • exp_pdf_server.dll
  • FaxImage.tif
  • GetFeatureDS.cs
  • HiJaak.Image
  • Imaging.Document
  • InfoPath.Application
  • infref.chm
  • InternalTailDS.HighlightedItem
  • InternalTailDS.ListHeight
  • InternalTailDS.SelectedItem
  • InternalTailDS.TailContext
  • IPM.Appointment
  • IPM.DistList
  • kernelBase.dll
  • meetings.asmx
  • mergedoc.rcd
  • METTrace.log
  • microsoftonline.com
  • mscreate.dir
  • msodatalast.dat
  • msohdinh.tmp
  • msosqmcached.dat
  • MySharePoints.ico
  • Node.StyleTree
  • Normal.dotm
  • NormalEmail.dotm
  • ODC.TableCollection
  • office-AppPrivilege.OPEP
  • OscAddin.SharePointProvider
  • Outlook.Application
  • Outlook.FileAttach
  • Paint.Picture
  • PersonaMenus.ribbonpp
  • pg_custom.xml
  • Photohse.Document
  • PhotoSuite.Image
  • PowerPoint.Application
  • PowerPoint.Slide
  • proppanel.xsn
  • prottpln.doc
  • RenderFrames.csv
  • sampledata.xml
  • SharePointPortalSite.ico
  • SharePointTeamSite.ico
  • skydocsservice.svc
  • SocialConnector.dll
  • typeSchema.xsd
  • UIAutomationCore.DLL
  • verifier.dll
  • WangImage.Document
  • Word.Application
  • Word.Document
  • xlimpconv.dll

As I go through functions that reference these strings I gain more insight into logging, debugging functions that are built-in into MS Office. In fact, the Office persistence mechanisms I discovered in the past are a direct result of digging in some of these artifacts…

And now it’s time to introduce a MsoFWzEqual and MsoFSzEqual functions that mso.dll relies on to compare many strings. I cannot list all the strings that these 2 functions operate on, but many of them are good pointers for further analysis as well. The comparisons include file extensions, MIME types, data block headers, etc. Yup, they are used during data parsing so highly possible there will be some vulns possible…

Not much, but at the same too much. You be the judge…