TL;DR: InfoPath is a fantastic way to run custom C# code, and we missed it as an attack vector sadly. At the moment it has been deprecated, but don't fret it's still everywhere!
So what is InfoPath; merely put InfoPath is a forms-creation and data-gathering tool that helps organizations streamline business processes[1]. The following research is a combination of co-workers, myself and prior work from the security community.
One of the primary drivers of this research is the ability to develop new methods of phishing. I'm a major fan of OLE, HTAs, and macros; but these payloads are often caught easily with proper process monitoring of execution.
Microsoft InfoPath
The InfoPath platform dates back to the early 2000's and has had a few significant overhauls, one of these in 2007 added the .NET features. This allowed developers to integrate into SharePoint and automation of large-scale enterprise data collection. Any time these elements exist it's easy to use them maliciously.
The InfoPath format was built more like a web page than anything else, a combination of XML and HTML allow custom views and data handling to be generated. You will find that the results of these forms are often submitted via email post completion.
InfoPath files are pretty simple, they use the .xsn extension and use the Hex header of: 4d 53 43 46. This format shares the same hex header as the Microsoft CAB format. This arrangement allows for archival at high compression ratios. The following are core files within this structure:
- .XSF - manifest file that describes the basic definition of other form files
- .XSL - Defines the transformation of data into different views
- .XSD - Defines the data source schema
- .DLL - Carries the custom logic built into .NET or COM
- HTML - Custom HTML/Images resource files and other resources for the form
Extracted below is an example excerpt from the CAB structure, this project also includes a sample "action" compiled within. These actions are similar to many Macro based phishing attacks that leverage specific activities such as a click or mouse over to execute code.
InfoPath Designer vs. Filler
One thing of decent conversation is the core differences between the two InfoPath products you need to be aware of.
- InfoPath Designer
- Included in the full version of office "Professional Editions."
- Can easily be obtained from MSDN (Microsoft Office 2013 Professional)
- The developer interface is used to build and publish these forms
- Includes basic template forms
- Easy UI Design
- Allows Red Teams to build awesome corp surveys
- Contains a devloper mode: https://msdn.microsoft.com/en-us/library/office/fp161226(v=office.15).aspx
- InfoPath Filler
- Think of the end-user component
- Simple to use UI that does not allow creation of forms
- Limited version, can not inspect source code or raw XML natively
- Often used within Outlook or web sources
Build Environment
While this post is not an inclusive resource for building these payloads, it more serves as the technical implementation and what is needed to begin researching these payloads. You will need to follow the install process in order:
- Windows 10 ProBuild: 16299
- Visual Studio Professional 2012
- Visual Studio C# Support
- Visual Studio Tools for Applications 2012
- Office Professional Plus 2013
- .NET Framework 3.5 SP1
InfoPath Payloads
During this process, I compiled a lot of resources needed to start using these forms. The resource can be found on the https://github.com/InfoPhish/InfoPhish Github page. It contains the PowerPoint talk, projects and compiled form examples and build tools. I originally gave this talk at https://www.arcticcon.com, an amazing small knit community conference focusing on TTPs and true red team operations.
InfoPath HelloWorld
The first project uses the HelloWorld.xsn Build file. This project is purely a popup box using .net message box namespaces. One important concept to understand is the ability to handle "Events," this is common with Microsoft platforms such as these. It helps developers standardize the internal API to the user front end interactions taking place, here is an example of the InternalStarup() function you use to Init:
void InternalStartup(object sender, EventArgs e) {((FormControl)sender).EventManager.FormEvents.ViewSwitched += new ViewSwitchedEventHandler(OnSwitchView); ((FormControl)sender).EventManager.FormEvents.Submit += new SubmitEventHandler(OnSubmit); ((FormControl)sender).EventManager.FormEvents.Sign += new SignEventHandler(OnSign); ((FormControl)sender).EventManager.FormEvents.Save += new SaveEventHandler(OnSave); ((FormControl)sender).EventManager.FormEvents.Merge += new MergeEventHandler(OnMerge);
}
The forms can support a multitude of event handle; most notably the following would most likely be used to execute code on an engagement:
FormEvents_<event>()Loading- Startup of the view (Before user interaction)Save- If the user saves the form (Maybe you want to clean up?)Sign- Once user signs the form with digital signatureSubmit- If you use a submit button binding
When complete and compied within visual studio you will see the following upon execution:
InfoPath Calc
As they always say CALC.EXE || GTFO; as calc.exe the core component of all payload testing. During this time there were a few lessons learned, specifically dealing with C# project settings that need to be configured. Take a moment to watch this video where settings were not properly configured:
You will soon find out that this code will not run, mainly because of the use of diagnostics system class. This code type requires the use of specific settings within you project configuration.
Unsafe Code
Using System.Diagnostics to create a process requires the following :
Allow unsafe codeflag setUnsafefunctions require this as well
Here was the configuration that seemed to work well with all of the projects.
There is also another factor outside of the C# project to take account for. InfoPath designated some specific security controls around what a form can and cannot do. These are broken down into security levels; these standards dictate the level of access a form has to the local resources as well as the user interactivity of the form. These must be configured to the highest setting if you want to run any code, but if you are just doing user data collection, you will notice you can get away with fewer rights, requiring no digital signature as we will see. Here is a small table I compiled to help break down the privilege rights as well as the slide from presentation if that's easier to digest.
| Type | Following will not work | Type | Can access the following | Type | Can access the following |
|---|---|---|---|---|---|
| RESTRICTED | Data connections | DOMAIN | Same domain as the form | FULL TRUST | Same domain as the form |
| RESTRICTED | Managed code and scripts | DOMAIN | Content in the local computer zone | FULL TRUST | All other domains, without first displaying a security message |
| RESTRICTED | Custom Dialog boxes | DOMAIN | Content in the Local intranet zone | FULL TRUST | Content in the local intranet zone |
| RESTRICTED | Microsoft ActiveX controls | DOMAIN | Local sandbox/cache | FULL TRUST | Files and settings on the computer |
These settings will also require you to sign the code within in the form. Obviously, tradecraft dictates this be appropriately configured. Either using a self-signed cert or an Extended Validation (EV) cert. Both which will work, but the target will be prompted with a self-signed cert sadly.
In the InfoPath Github repo will find New-SelfSignedCertificateEx.ps1. This script is easy to use, then directly using MMC certificate snapin import the newly created code signing cert. IF adequately configured you will be able to match the pretext of the phishing campaign.
As you can see from the above figure, this pretext was developed to match Symantic and seems to look relatively clean.
Calc Win
Once all of these settings are configured, we should now be able to run our calc.exe payload properly. This uses some basic code from System.Diagnostics to create process basically, a fairly contributed sample for simplicity. Again all of these projects can be found here: https://github.com/InfoPhish/InfoPhish
InfoPath CobaltStrike Beacon
You ultimately want to know how to weaponize this a TTP, for this example we will be using a CobaltStrike (CS) as our payload. Using the payload generator, we can generate a C# shellcode runner within the CS platform[^2]
You will quickly find that this will not be satisfactory for active engagement, as you will be running in the current context of InfoPath and will be killed upon the parent process ending so you will need either build in auto-injection or migration.
Note: If you have not gotten the chance to play with CS I highly recommend you do, it's a great threat emulation platform.
InfoPath PE Hollowing
To solve this issue I worked with Aaron Bray @Ambray to develop a method that would be extensible to run payloads of any choice without many configurations. To do this, he developed an in-memory C# runner. This wraps your C# payload code and allows you ShellLoader namespace into your project. This will allow for remote process PE Hollowing.
This is broken down into five (5) initial phases of execution:
- Execute InfoPath Event Handler
- Start a process of choice (Suspended)
- Map a view of PIC code buffer (Shellcode) into it main thread
- Patch original process entry point
- Resume execution of main thread
InfoPath Tradecraft: Tips & Tricks
I can't stress enough this isn't just a code execution its also a TTP; it requires a bit of pretext and reliability to blend in and to leave your target with some satisfaction post-execution.
INVEST IN BUILDING A STORY NOT JUST A PAYLOAD
- New-SelfSignedCertificate Certificate Creation
- Create the custom self-signed certs to match the pretext of the phish. If possible roll EV certs for an easy win.
- Create a Pretext to Match
- Take the time build out the scenario, even if you get exec(), it's always nice to leave the warm and fuzzy.
I put all of this together as an example; the following video is an example of how a phishing campaign could be conducted sporting the C# PE Hollowing methodology.
InfoPath Deployment Options
Finally, you have a few options to deploy this code, as this platform is meant for enterprise solutions. From prior research, I have come across three (3) viable solutions to deploy this project.
- WevDav - A great guide here
- Easy deployment options for content authoring
- Supported by InfoPath
- Allows you to “Update" the project/payload on the fly
- Allows you to send a link or template file
- Sharepoint
- Allows you to deploy internally
- Deploy to cloud public access with no auth, can be done with 365
- Email
- Create new Emails that contain the form!
- Use this don't want to host externally, but I am subject to email attachment scanning/implosion
- InfoPath filler is still required on the host, so beware
Credit:
- Steve Borosh@424f424f – Helped with deployment
- Chris Ross @Xorrior – Helped with phishing aspects
- Aaron Bray @Ambray – Built PE Hollowing
Resources: https://github.com/InfoPhish/InfoPhish/
Article Link: Blog grid | Obscurity Labs