Attachment Redirect #513

dragontologist · 2017-01-12T20:20:14Z

I'm trying to track whether users are opening fake attachments. I'm starting with an HTML file, by redirecting them to the "You've been Phished" page I set up, but it doesn't have the tracker included so it's not tracking whether they are actually opening it. It would be useful if the page could generate the file below, or for more custom files, read the attachment and replace the template variables.

``<html>
<head>
	<meta http-equiv="refresh" content="0;url={{.URL}}" />
	<title></title>
</head>
<body>{{.Tracker}}</body>
</html>`

`

The text was updated successfully, but these errors were encountered:

jordan-wright · 2017-01-15T20:05:17Z

Unfortunately, we don't support templates in attachments at this time. It's something that I'm considering adding, but it'll likely be a bit before it's merged in.

vanhecke · 2017-01-30T12:06:30Z

I believe that the ability to apply templating on attachments would be a huge benefit.
However, in stead of doing the regular templating like in the email and landing page, I believe it would be better if this was possible through a external script.

idea: for each attachment you can define a "pre-processor" option which is a filepath to a script.
Gophish then calls this script with the FirstName, LastName, Position, Email, RID/URL parameters.
The pre-processor script can then perform whatever it needs to do, and put the custom attachment in a place gophish can find it.

Templating attachments should support text/html, office docs, binaries, etc.
Keeping all that functionality within the gophish core sounds like a bad idea at this point imho.

jordan-wright · 2017-01-31T04:43:29Z

This one is tricky for a few reasons. On one hand, I like Gophish to "just work" out of the box as much as possible, because that makes it accessible to more people. Ideally, common attachments would follow suit in that it would "just work" to honor template variables on multiple formats.

The problem as you called out is that this is a bunch of work. Supporting things like office docs and binaries is really tricky.

Then there's the problems of making the option for pre-processors. It would require users to understand how to write code that can handle the attachment. Then, I would need to figure out how to have Gophish call these pre-processors in a safe way. Then, we would inevitably be asked to support pre-processors and handle all the issues that arise from them. And if we require them for every attachment, it makes things that much more difficult for the average use case.

I'm considering just adding basic support for things like non-binary files (how to determine if a file is "non-binary" is TBD). This would take care of the majority of issues. Then we could consider other common scenarios like office docs on a case-by-case basis.

What do y'all think?

vanhecke · 2017-01-31T08:13:58Z

@jordan-wright
Indeed, gophish should "just work".

If there is a easy to implement interface that would be great too (not just straight calling some golang template library).

Maybe it's time to think about adding some sort of plugin capability? So someone like me can share his bad code with other without trying to add it to the gophish core.

ghost · 2017-02-10T10:04:06Z

I'm utilising Powershell Empire (PSE) to generate attachments like encrypted macros/hta files etc. What I wanted to do was include in the actual action performed by the macro or HTA file - simply open the URL to gophish for the campaign with the tracking ID. I understand that you cannot currently find/replace the {{.Tracker}} in an attachment as the macro code may have been obfuscated to hide the URL when built by the original tool.

But how about being able to publish the Campaign ID so that for say HTA files I could append the Campaign ID on the callback URL to GoPhish - so I atleast know somebody fell for the HTA file attachment vector? Currently my HTA will actually callback PSE rather than callback back to a gophish landing page. Could have a silent callback on gophish for the campaign to indicate a user has run the attachment but do not show any action from gophish but let the attachment continue onto beef or PSE? That would mean that gophish has had visibility of the attachment opening too.

I combine Powershell Empire and GoPhish - I use PSE to create the attachment like a word doc with encrypted macro which calls PSE back and I will then be able to look at the connect computer details for the username etc.

I was also thinking of embedding the BEEF hook into a landing page in GoPhish so I can clean details about the connected machine ;-)

You may want to look at some form of integration with beef/Powershell Empire.

Otherwise thanks for great product so far.

ekleintop · 2017-02-10T15:22:37Z

For tracking attachment opening I took this approach. With some code changes I managed to add the RId value to the attachment during the worker.go process. It works for earlier versions of Office files only (.doc and .xls) so it has limitations. But for us it met our use case. I tested saving as Word/Excel 97-2003.

It starts by creating a Word/Excel file and adding an arbitrary value, I chose {{.RId}}, to one of the document properties, e.g. Title, Subject, etc. I used the Tag property. A hex view of the attachment shows the Tag {{.RId}} in plaintext. Perfect, I have a place holder for the RId I can see. Then I add the attachment to a template in GoPhish.

During the campaign worker.go then decodes the base64 attachment, looks for {{.RId}} placeholder, replaces it with the RId of the target (e.g. {{.RId}} -> BR549xy), encodes the attachment back to base64 and sends it on. For each target I now have their unique RId embedded in their attachment. I can now craft a macro to send a request to the phishing server with the RId when the macro executes.

I added an EnabledTracker section in route.go that is triggered by "/enabled" in the url, e.g. http://phishing_server:8080/enabled?rid=BR549xy. It's a copy of the PhishingTracker section with one exception, it tags the event as "content enabled". When the macro sends the url it creates an event in the database with all the particulars for the target.

I modified a bit more code to add the "content enabled" event to the campaign results and to treat "content enabled" as a successful phish. See screenshot here: https://drive.google.com/file/d/0B6Ey1DtpijJRdzVmbXlSRFRwR0U/view?usp=sharing

Beyond worker.go and route.go, other code changes were made in models.go, campaign.go, campaign_results.js, dashboard.js, and main.css. I am continuing to test various scenarios but so far so good.

BTW I love GoPhish. Truly easy to deploy and use. Very nice work!

ghost · 2017-02-13T08:52:56Z

@ekleintop Thanks for sharing your idea. I'm gonna spend some time learning more about 'go' which shouldn't take too long and I can have a dig around the codebase.

Thanks again.

jordan-wright · 2017-02-14T03:02:06Z

@ekleintop Nice! This sounds similar to the work from @jli53 in #260. Basically, appending the Rid to the end of the document and reading that from the macro.

The part that's tricky on this is allowing users to customize the document. I suppose a workflow could be to let the user download the template and then they could upload the customized doc... but this seems like it might be tricky and we would have to figure out a UI that makes this clean.

Then we have to consider that many Gophish users won't have Word, Excel, etc. installed, breaking this feature for them.

The other option - the one I'm leaning most toward at this time - is to just expose a handler like the one you made for triggering on attachment opens. That way, anyone can create whatever attachments they want that point to this handler and, when they're opened, the results are logged.

It seems like that would be a good middle ground so we don't wind up supporting a whole bunch of filetypes for attachments while still offering the capability to track attachments.

ekleintop · 2017-02-14T12:54:29Z

@jordan-wright Thanks!

I saw #260 and my first testing was appending the RId to the filename (pre-extension like "phishing doc BR549xy.doc") similar to @jli53's code. It worked perfectly. I only went with the "tag" method when I discovered it was accessible without a lot of additional effort and fits our use case (MS Office shop). But it is definitely limited to early Office formats.

From what I saw from my earlier test, I agree with you that appending the RId to the filename and then exposing a handler is perfect middle ground. Trying to support the myriad of file formats available would be a daunting task to be sure. The new shorter tracker id makes the filename less suspicious to the target. It keeps to your "just works" mantra as it will work with any attachment. And there's plenty of flexibility on the back end to execute communication with the handler.

Maybe the UI could have an option to prepend or append the tracker to the filename. You could use prepend for a more phishy look to test targets, and append for less phishy looking. Though that may complicate things for the handler. For an out of the box solution for folks with less technical/coding chops, maybe provide a template doc or two with the handler code built in. I would think most attachments require end user development for the content. It looked like @jli53 was providing some sort of template doc (b.doc).

IAMPi · 2017-02-18T17:20:47Z

Just to add to this discussion. We created a mail proxy using python. It strips the URL/RID from the gophish email and inserts it into the attachments. Right now we support two types of attachments.

html document with the URL inside. The file gets renamed to .docx
Word document with macro thats reads the RID from the filename( similar to Add the feature for automatically adding attachments with tracking function #260 though we didn't know that Add the feature for automatically adding attachments with tracking function #260 existed until now)

I like Ekleintop's approach since we are still running a gophish version with long RIDs which makes the attachments look suspicious. We will probably incorporate that instead. I like the proxy approach because it gives us the flexibility to add new features like the one from the Phishery project on github without making gophish suffer from feature bloat. We'll be releasing the proxy source once we clean it up a bit and make it some what respectable for public consumption.

I also agree with Ekleintop....gophish is great. Thanks Jordan

b174 · 2017-08-07T13:46:43Z

@ekleintop Hey, nice job!

Are you still working on this issue?

How did you automatically create a Word document in the first place?
How did you handle base64 decoding/encoding?
I think it's a great idea and as I'm trying to do something similar myself would appreciate if you would share some more information on this part. I'm trying to create it as a HTML template, adding rid parameter when launching and then converting it to word. How did you handle it?

Thank you.

ekleintop · 2017-08-07T14:48:54Z

b174,

Thanks! I haven't worked on this for some time but I'll take a shot.

I did not create the Word document automatically, it was all done manually. I added a unique value in the document Title property (something like "{{.RId}}", "~~~~~~~", etc.). I also manually added VB code to query the Title property to get the target's unique ID and send it back to GoPhish to tell me when the macro was enabled (successful phish). It was well beyond my Go skills to try and create a Word doc with VB code programmatically (if it can in fact be done using Go). I saved it in Word 97-2003 format since the Title property is visible in the Base64 decoded raw file. Newer versions of Word required not just Base64 decoding but "unpacking" the Word file to find the tag. It works for Excel as well.
The attached document is modified for each target during Worker.go processing. This way I have only one attachment and make it unique for every target. In Worker.go I added code:
a. base64.StdEncoding.DecodeString (to decode the attachment)
b. bytes.Replace (to replace the tag with the target's unique id)
c. base64.StdEncoding.EncodeString (encode it again)
d. Worker.go send it on to the target.

Hope this helps.

Eric

choikappa · 2017-12-08T20:09:58Z

@IAMPi

Is there any update on when you would release the code?
Else, would you be willing to share with me as I would like to experiment in a current setting I am working on?

workandresearchgithub · 2018-04-17T02:29:46Z

Here's an alternative, very crude way to do this, though it lacks a simple way to gain attribution in the main campaign. (If attribution is really important, you can always cross reference to attain it)

create campaign Better Go+AngularJS Separation #1 with one recipient.
capture the full URL and RID for the one recipient.
create the attachment file, in your chosen format (we tested with MS Word and Adobe Acrobat), and embed the URL/RID.
create campaign Add gzip support #2, and attach the file created in the previous step.
send campaign to as many users as you want.
You end reports can show how many people were tested, how many opened the email (if they allow images), how many clicked on the link, and how many opened the attachment.

If you really want attribution of who opened the attachment, you'll have to cross reference the data from campaign #1 and #2, by time and source IP address.

Anyway, very ugly, but it didn't require writing any code, and made our customer very happy we could accommodate their request for and attachment.

cyberpewpew · 2018-05-18T01:22:36Z

@workandresearchgithub Thanks for sharing this workaround! May I ask how did you embed the URL/RID in MS Word/Adobe Acrobat?

Thanks!

cyberpewpew · 2018-05-18T01:45:25Z

@IAMPi . Hi, there. Want to check if your the proxy source once is available? I'm keen to test this out.

Would like to know how did you strip the URL/RID from the gophish email and inserts it into the attachment like this: html document with the URL inside. The file gets renamed to .docx

ekleintop · 2018-05-21T12:29:25Z

@mirkatson

No ETA on code release. It's currently very crude (I am an IT auditor not a dev ;) I'll be dusting it off in the next month or so as we will be firing up another campaign. One of my goals is to get a cleaner repo setup. See my posts above from Feb 10 and Aug 7 on how I embed the unique RID for each user. It currently only works for older versions of Office, but someone better at GO than I may have a solution for newer Office or PDFs.

Eric

IAMPi · 2018-05-22T05:38:05Z

@mirkatson

We created our own tags. When we generate our email template we do something like [[attachmentURL: {{.TrackingURL}}]]. The proxy then parses the email and grabs the tracking URL and inserts into the html file then renames the file to docx.

I'll look into seeing if I can get it released in its current state. The problem is we've moved away from Gophish to a more commercial tool that automates the infrastructure aspect of phishing. Its hard allocating resources to a tool we kind of no longer use. Still love Gophish though.

cyberpewpew · 2018-08-23T02:46:50Z

@ekleintop

Sorry to bother. Just want to check if you happened to release the code for your implementation. I've tried to do something similar but it's not working. Cheers.

tratatoxa · 2019-07-01T08:29:32Z

@ekleintop

Sorry to bother. Just want to check if you happened to release the code for your implementation. I've tried to do something similar but it's not working. Cheers.

@ekleintop May I ask you to share your attachment tracking code? Really need this, thanks.

rc4 · 2019-08-20T02:38:08Z

If you aren't averse to semi-hacky workarounds, I've created a python script that will inject the user's RID into specially-crafted outbound office documents using an SMTP transport filter (requires a local SMTP server on the GoPhish box). Check it out here: https://github.com/rc4/gophish-macro-attachment/

tratatoxa · 2019-08-20T09:19:29Z

If you aren't averse to semi-hacky workarounds, I've created a python script that will inject the user's RID into specially-crafted outbound office documents using an SMTP transport filter (requires a local SMTP server on the GoPhish box). Check it out here: https://github.com/rc4/gophish-macro-attachment/

Thanks a lot! Totally no hacky needs, only employee testing.

TairaNoMasakado · 2021-08-10T14:28:35Z

How to include word documents on Gophish?

glennzw · 2022-04-19T11:58:02Z

Closing out as we now have attachment tracking support #1936

jordan-wright added the question label Jan 31, 2017

workandresearchgithub mentioned this issue Apr 17, 2018

Tracking statistics of attachments being opened #227

Open

jordan-wright mentioned this issue Aug 24, 2018

Attachment Tracking & Open Rate #1176

Closed

glennzw mentioned this issue Aug 15, 2020

Added support for templating attachments #1936

Merged

glennzw closed this as completed Apr 19, 2022

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Attachment Redirect #513

Attachment Redirect #513

dragontologist commented Jan 12, 2017 •

edited

jordan-wright commented Jan 15, 2017

vanhecke commented Jan 30, 2017

jordan-wright commented Jan 31, 2017

vanhecke commented Jan 31, 2017

ghost commented Feb 10, 2017 •

edited by ghost

ekleintop commented Feb 10, 2017

ghost commented Feb 13, 2017

jordan-wright commented Feb 14, 2017

ekleintop commented Feb 14, 2017

IAMPi commented Feb 18, 2017

b174 commented Aug 7, 2017

ekleintop commented Aug 7, 2017

choikappa commented Dec 8, 2017

workandresearchgithub commented Apr 17, 2018

cyberpewpew commented May 18, 2018

cyberpewpew commented May 18, 2018

ekleintop commented May 21, 2018

IAMPi commented May 22, 2018

cyberpewpew commented Aug 23, 2018

tratatoxa commented Jul 1, 2019

rc4 commented Aug 20, 2019

tratatoxa commented Aug 20, 2019

TairaNoMasakado commented Aug 10, 2021

glennzw commented Apr 19, 2022

Attachment Redirect #513

Attachment Redirect #513

Comments

dragontologist commented Jan 12, 2017 • edited

jordan-wright commented Jan 15, 2017

vanhecke commented Jan 30, 2017

jordan-wright commented Jan 31, 2017

vanhecke commented Jan 31, 2017

ghost commented Feb 10, 2017 • edited by ghost

ekleintop commented Feb 10, 2017

ghost commented Feb 13, 2017

jordan-wright commented Feb 14, 2017

ekleintop commented Feb 14, 2017

IAMPi commented Feb 18, 2017

b174 commented Aug 7, 2017

ekleintop commented Aug 7, 2017

choikappa commented Dec 8, 2017

workandresearchgithub commented Apr 17, 2018

cyberpewpew commented May 18, 2018

cyberpewpew commented May 18, 2018

ekleintop commented May 21, 2018

IAMPi commented May 22, 2018

cyberpewpew commented Aug 23, 2018

tratatoxa commented Jul 1, 2019

rc4 commented Aug 20, 2019

tratatoxa commented Aug 20, 2019

TairaNoMasakado commented Aug 10, 2021

glennzw commented Apr 19, 2022

dragontologist commented Jan 12, 2017 •

edited

ghost commented Feb 10, 2017 •

edited by ghost