Network Scanning #1 / Port Scanning, Anonymous FTP Querying, UDP Flooding

There exist a variety of mechanisms an attacker may use to perform network-based activities against a remote or local host, with many of them existing in the form of well-established mechanisms such as ‘nmap’ or other well-known utilities.  This post will attempt to demonstrate how to establish a basic TCP Connection to a remote host as well as showing how to utilize anonymous FTP logins and basic UDP Port flooding capabilities, to be expanded on in later posts.

The overall script is designed to take a variety of arguments as input such as the target-host, target-ports for scanning and whether or not to attempt anonymous FTP login or UDP flooding on the specified ports.  Typically, port scanning programs will check all well-known ports (1-1024) or even more, but this script will be very basic in that it will only check ports specified by the user.  It would be trivial to remove this and instead have it iterate through a port list.  The code snippet below demonstrates a basic port scanning function which will iterate through all ports given in the ‘target_Ports’ list, specified outside the scope of the local function by the given user inputs or statically populated with any desired port.


Here we see that threading is utilized to allow concurrent execution of the ‘Connect()’ function in order to speed up the overall scanning process.  Zooming in to the ‘Connect’ function, we can observe how the parameter arguments are utilized in order to make a socket connection to the remote host on the target port, with a custom payload available that can be tuned by the developer to whatever is required.


It would be possible to analyze the ‘feedback’ response of the remote host in order to determine if the socket was immediately reset or if a legitimate response other than a TCP RST was received, allowing for the determination of whether or not a target port is ‘open’, ‘filtered’ or ‘closed’.  An immediate TCP RST would indicate it is likely ‘closed’ or perhaps ‘filtered’ while any other response, such as a query indicating the payload is invalid, might indicate the port is ‘open’.  This type of information can be useful to attackers performing initial reconnaissance.

An easy way to perform an anonymous FTP login attempt would be through the usage of the ‘ftplib’ module included in Python.  A small function demonstrating this sort of capability with a randomly generated email address is shown in the code snippets below.



Flooding a port is slightly more complicated, but not much more.  For this example, we will utilize randomized UDP datagrams and attempt to continuously send them to the specified ports given by user arguments.  The initial function beginning this behavior is shown below.


The above code takes as argument the specified target host, the list of ports given in user arguments as well as the time that flooding should occur for, also given in the user arguments in terms of seconds.  Each port to be flooded is given its own process in order to execute concurrently using the ‘port_Flooder’ class, described in more detail below.


Above we see the beginning of the port_Flooder class, existing as a derivative of multiprocessing.process.BaseProcess, which issues a ‘run’ statement in the initialization of each class in order to begin immediate functionality.  The self function ‘flood_port’ is called for each instance, shown in the image below.


‘flood_port’ essentially takes in as arguments the target host, target port and the time that flooding should occur for and uses these to create a new socket which is utilized to send data over via UDP.  Packet contents are given via the ‘random_data’ variable which consists of random data with the generation mechanism specific to the current OS.  This data is then used through the ‘socket.sendto’ function and sent to the target host/port pair.  Unless this is performed hundreds or thousands of times simultaneously with various hosts, it is unlikely this alone will effect the performance of any server due to most autonomous mechanisms which exist to prevent this type of basic DoS attack.

Anti-Forensics #1 / Time-Line Obfuscation

Being able to track the activity of malicious software on a particular host is critically important to understanding the potential impact and consequences that will arise from its execution.  As such, designers of malware will attempt to utilize a variety of anti-forensics mechanisms in order to evade detection or obfuscate the actions taken in order to make it more difficult for security investigators to assemble action time-lines.  This can be achieved through a variety of methods but today I am discussing simple time-line alteration techniques that may often be seen as side modules existing within larger packages of malware.

In particular, altering the modification, access and creation (MAC) times of files can greatly hinder investigative attempts to understand when and how different actions on a system were taken.  This is more easily done through direct struct manipulation in C but I am utilizing Python 3+ in order to modify MAC times.  Python can easily handle changing Access and Modification times but modifying the creation time requires a more in-depth examination of C-Structs and as such I will be using the imports ‘win32file’ and ‘pywintypes’ and ‘win32api’ to achieve easier handling and manipulation of Windows APIs and file-structure data.

The first step I take in achieving a realistic time-line is to generate a random date-time sequence which will be used when later modifying file MAC times.  In order to do this, I first pull the ‘start date’ from the local device’s System Event Log by opening up the event log and getting the date from the earliest record present, as shown below.



The above code opens up a handle using the pre-defined variables and then uses a basic loop to get the ‘TimeGenerated’ data from the earliest record in the log.  If the log isn’t regularly wiped, this will typically be from when the OS was installed, giving us some boundaries which can be utilized for date-time generation if we wish to remain ‘in-bounds’ in regards to accurate time-setting, although this isn’t completely necessary.  The next step taken is to create  function which, when utilized, will generate a random date-time within the boundary given above as well as the system’s current date-time.  This function is shown below.


The above code can be written in a variety of ways and is very simplistic, ignoring many fringe cases and achieving a very naive mechanism to generate random date-times.  These are utilized in the next stage of the process to alter MAC times for a given file.  The overall script is able to take a directory as input and, when given, will iterate through the entire directory and any sub-directories and will pass any detected file through the ‘randomizeFileTime’ function given below.


The above function uses ‘os.utime’, a Python native function under the ‘os’ import to modify both Modification and Access time of files but it cannot natively alter the Creation time.  To do that, I prepare a time in the necessary C-struct format under the variable ‘ct’ and then use the ‘CreateFile’, ‘Time’ and ‘SetFileTime’ functions included within ‘win32file’ and ‘pywintypes’ to modify the Creation time.  This results in files having a completely randomized MAC time similar to utilizing the ‘Timestomper’ software released many years ago.

Unfortunately, this type of work can be easily reversed by a skilled investigator through System Event log examination and a basic script which ‘un-does’ the actions performed within this obfuscation attack.  One way to make this more difficult is to simultaneously modify the System Time in order to effectively ‘scramble’ the System Event log, making reconstruction much more tedious and time-consuming.  This is done in a simple ‘while’ loop for demonstration purposes but could just as easily be performed via threading to achieve concurrent execution.  The above random-date-time generator is utilized to create variables which are input to the basic line of code shown below.


This will change the system time using the previously mentioned imports in a very simple ‘one-liner’.  This is achievable through pure python means but is much more tedious to perform.  One other action that may be taken to increase the difficulty of ‘un-scrambling’ the event log would be to alter the current time-zone previous to modification of each file-time.  This may also be done through Win32API interaction and the method used is shown below.


The ‘tz’ variable includes a long-list of all potential Time Zones present in the Windows 10 OS while ‘tzpath’ gives the expected path in the Registry for time-zone value manipulation, shown in the below image.


The code snippet above demonstrates how, for each file, previous to having the file-time randomized a random time-zone is selected from ‘tz’ and the registry value for current Time-Zone is modified, further obfuscating system event logs and increasing the tediousness of investigations.  Further-more, after script completion, an attempt to wipe all existing event logs is made via the code snippet given below.


This code attempts to iterate through all existing logs and uses native Windows functions to attempt clearing logs.  If allowed, this can make it very difficult for forensic investigators to determine specific time-lines if no external reporting or auditing systems are in place.  There is one final technique utilized in this script to attempt time-line obfuscation, but which does not quite work as expected, although I will include mention of it here.  I noticed in my testing that there exists a ‘System Uptime’ event in the Event Logs which seems to ‘tick’ every second since the system has last started.  It seems through research that this event is dependent upon the ‘LastBootUpTime’ property of the Window’s CIM_OperatingSystem information class and altering this cannot be done very easily.  I have attempted to write a new ‘Managed Object Format’ class which will over-write the existing class and attempt to define a new value for ‘LastBootUpTime’ property.  The initial function for this is shown below.


The above function, when called, will attempt to write a ‘.mof’ file containing the above code with a randomized date-time inserted into the code.  This alone is not enough, as this function would simply leave the file on the system but that would do nothing on its own.


The code snippet attempts to call the writing-MOF function as well as utilize ‘’ in an attempt to force an update to the existing class via the command-line.  Additionally PowerShell is utilized throughout in order to learn what the original ‘LastBootUpTime’ is as well as to verify that it is modified after MOF compilation.



Overall, the above code, when combined, attempts to obfuscate malicious software actions and would be part of a larger package.  This ‘larger package’ may attempt some form of data exfiltration or persistence achievements and this type of obfuscation will try to hide the greater intent of the package and make it very difficult for security investigators to understand what happened or construct accurate time-lines.

Some screenshots of this script in action are shown below.