Written By: ȺʁɱªÐą



Project Status: Complete

Spoiler (Click to View)
Section Complete

• 1.1 Central Network Communication
  -- Advanced Knowledge - IPv4 / OSI Model
  
• 1.2 Picking the right R.A.T. for you
  -- Additional Reading: Hacker Riskware
  
• 1.3 Networking from a Remote Administrative Point of View. (R.A.T. POV)
  - Windows Firewall
  
• 1.4 Install and Configuration of your R.A.T. - Covers Install and Configuration of Luminosity Link 1.2 and Imminent Monitor 3
  - Official Guides: Nanocore RAT / Babylon RAT Setup and Config / Babylon C++ RAT #2 #2 / Luminosity Link Resources LL Setup Guide / Imminent Monitor 3 Tutorial Videos
  - User Guides: Dark Comet
  

Spoiler (Click to View)

• 2.1 - R.A.T. Health and Safety
  
• 2.2 - Controllers Security Principals
  
• 2.3 - Clients Security Precautions
  

Written By: ȺʁɱªÐą

Main Course Thread

Spoiler (Click to View)
Figure 1 – 2 Computers in Communication.



In this model we have the simplest figure of computer networking. 2 machines in direct communication using a form of networking protocol (Likely IPv4 or IPv6). In this model the computers are shown with no protective measures, firewalls or anti-virus/security protection software elements in place. – A scenario now a days which is highly unlikely.

Figure 2 – 2 Computers in Communication with Firewall/Security in Place.



In Figure 2 we examine a more likely scenario where a computer has running security provisions in place. – In this example a firewall is in place on machine #1 – This scenario allows for machine #1 to accept requested information, send information outbound, however restrict unauthorized communication from machine #2, or other machines which may attempt communication.

Understanding your networks security provisions will greatly reduce troubleshooting of connectivity problems later on.
Every layer in the network has the potential to have another form of network security in place. It is highly recommended before attempting to start use of Remote Administrative tools the user sit down and plan the networks design and strategy out beforehand. Use of Microsoft Visio is a fantastic resource for such network planning.

Figure 3 – A Typical Home Network Design



In Figure 3 we have a Typical Home Network design, with common elements of network connectivity. A Cable Modem (Or DSL) which provides the network gateway and hardware interface for the communication. The Wireless Router which provides resource sharing of the modems internet connectivity, and the various devices used to access the network.
However, there are hidden or less known layers which also exist within even the simplest of networks such as detailed in figure 3.

 
Figure 4 – Detailed Typical Home Network Design



In Figure 4 we examine a more detailed, but “same” network configuration. Just with a more accurate view of possible network boundaries.
Each device presents its own unique security boundaries and configurations. Workstation and Laptop terminals employ software/OS firewall security and likely Anti-viral software. Network peripherals such as Routers and Modems (or Combo devices) also present firewalls which are hardware based and accessed through the devices interface (Likely a web browser accessible configuration page). Each and Every device and security measure along the network path/route from the Internet WAN to the device being used by the user to access such Remote Administrative tasks MUST BE CORRECTLY configured to allow the network traffic to pass. In more complex networks, this can become especially tricky for some users if they do not have the correct network privileges or rights to modify the required settings.

Written By: ȺʁɱªÐą

Main Course Thread

Written By:  ȺʁɱªÐą

Main Course Thread

Spoiler (Click to View)I need coffee. F%*^ you brb

We examine a "A-typical" network configuration.  Call it home diagram #1



But my network is different
- Of course it is.  All networks will vary in design.

Spoiler (Click to View)

We examine the Home network, and the first obvious situation consideration is the designation of a host controller.
For intensive purposes, I have labeled a laptop as "Hacktop"
- this will be our controller.

Keeping this as SIMPLE as plausible in this scenario.  Bear with me while I attempt to visually describe this concept.



We select a terminal to play CONTROLLER  In this instance, the laptop named "Hacktop"
At this point the remaining network devices are to be ignored for all intensive networking purposes.



- Assigning the terminal to static IP# addressing:
Armada, when is static internal addressing suitable?
- This answer varies.  In general I would suggest this solution if the controller is less likely to be transported around or access the network from multiple or various network connection points.

Hacktop is now assigned a IPv4 interface of 192.168.1.50
-How to statically assign IP addressing

We now must look at the networking from the outside perspective.
- I have a controller I am suppose to speak to, but it resides within layers of security.
How do I communicate with it?
So lets start with the obvious


The end game is a Remote Administrative Binary must speak to the Host Controller.  In this example "Hacktop"

Spoiler (Click to View)
Regardless of the device used, all network appliances have a fairly typical Port forwarding interface.  I mean you can only make the layout of the settings so unique.  Thus regardless of madel brand, all Port fowarding/Firewall configurations have a A-typical layout.

In this article we will take a quick look at Netgear and Linksys branded port forwarding screens





As is clearly visible by either configuration.  Some typical elements exist:

Application\Service Name - The name you have given for the firewall exception - Name this something you will remember what it is, but not totally obvious either.  (Dont call it Dark Comet for example, call it remote conectivity)
Port forward start and stop ports - This will typically be a singe port instead of a range of ports.  Unless of course you have chosen to run your service on a range of ports for management reasons, we will assume a single port for this article of Port 1337
Internal IP# - This is the designated machines internal IP# within the users LAN.  This IP# will typically start with the numbers 192.168.xxx.xxx or 10.1.xxx.xxx
And Protocol - Users will want to select either BOTH UDP/TCP or only TCP communication for the type of protocol to be utilized.

Important Note on Port Forwarding and Internal IP#:
Routers will blindly pass traffic to the designated internally assigned IP# without question.  This being said, the router assumes the administrator has correctly configured the port forwarding and does not check if the Internal IP# it has been directed to forward communication on is in fact a live responding IP#.

This being said, Internal LAN IP#'s are also generally considered dynamic IP#'s as well.  What does this mean to the Remote Admin?  as opposed to statically assigned IP#'s which will not change, dynamic IP#'s request a IP# from the router.  The routing device then pulls a IP# from a pool of available IP#'s and gives it to the device.  This IP# can change on a daily basis if the network sees a lot of devices connect and disconnect to it.  It is for this purpose.  If the controller's machine is not to move often or change networks on a regular basis.  It is best recommended to consider statically assigning an internal IP# to avoid trouble shooting connectivity at a later time.

Written By: ȺʁɱªÐą

Main Course Thread

Spoiler (Click to View)After starting LuminosityLink head over to the "Server Management" Tab and find "Client Builder"

Its important to enter the correct Dynamic DNS (Figure 1) and the correct port (Figure 2). Enter the port you forwarded through your router or VPN.
(I recommend using all settings within LuminosityLink, but that really depends on your crypter. Be sure to check that before building your stub.)

Spoiler (Click to View)
Still under the "Server Management" Tab find "Connection"

Right click - Add New Port -> Enter the port you forwarded and click "Start Listenin". It is very important that you start listening to the port, or else you will not get any connections.

Spoiler (Click to View)Go back to the "Server Management" Tab and find "Client Builder"

Double check that all your settings are good, then click BUILD CLIENT BINARY

You have now setup LuminosityLink correctly and you are ready to crypt it and start spreading.
If you port forwarded correctly and setup your Dynamic DNS you should now get connections when people execute your binary.
To see your connected clients head over to "Machine List"

Spoiler (Click to View)

On successful login, users will be presented with the controller interface:

Spoiler (Click to View)Users are directed to navigate to the "Settings" tab of the IM3 controller:


Within the settings area, there are 2 TABS to take note of in the upper portion of the controllers window. "General" and "Ports"
- I recommend enabling port listening on startup.
Other options can be configured to administrators liking. (Notifications etc).

After the user is satisfied with the General settings, they are then directed to navigate to the Ports TAB.



By Right Clicking on the interface, users will be given the Ports menu dialog where they can add or remove ports to listen to. - Select "Add Port" and input a "non standard Remote Administrative Port"
- This implies a port not typical to the base configuration of your controller, in IM3 this port is 9003. So use of a port OTHER THAN 9003 is recommended.



After users successfully select a port, they then click the "Start Listening" in the lower right of the interface to actively listen on the desired port.

IMPORTANT NOTE: Users must be actively listening to the desired port, before they can successfully test port forwarding configurations.

Spoiler (Click to View)After successful configuration of the controller. Users now need the Binary to deploy to HOST machines.
Users must navigate to the "Client Builder" tab in the IM3 Controllers interface.


Network Settings:
IP/DNS: This is the Controllers host address. This is required to be valid and resolvable. Failure will result in the deployed binaries failing to connect for commands from the controller. It is recommended users define a DNS server in place of a physical hard coded IP#. This is helpful for when the controller is either mobile or must deploy the controller software to another system or service. Allowing them to remain in control of the remote administrative machines.
Port: This is the communications port in which all network communication will take place on between the Binary and the Controller. This port must be IDENTICAL to the one(s) configured in the controllers interface (Step2, Ports TAB)
Client Group: THis option is used for Client organization and "grouping"

• Workstation Class
  
• Server Class
  
• Home User Class
  
• etc...
  

Mutex: This function is similar to a crypters binary string. This is used for the compile portion where this is the encoded "decryption string" allowing the base code to be obfuscated from prying eyes.
- Hit this option only ONCE. (Hitting it numerous times makes no difference, it generates a randomized string) However, always ensure to hit this button on all builds.


Client Startup:
The options and features within this drop down tab are the clients configurations to ensure the Remote Admin service starts up when the machine is booted up, or rebooted.
Unless there are specific environmental conditions to consider, users are best to enable all options within this panel.


Module Protection:
In this portion the builder handles its own binaries protection within the HOST client systems. These options are designed to prevent over zealous security software from removal of the Remote Administrative client assuming it is malicious. Again, unless specific environmental conditions must be met, users are best recommended to enable all options.


Assemly Information and Builder:

These next 2 tabs are pretty straight forward.
Assembly Information: Is the information the binary file will display if the element is inspected by the system. IE - User right clicks and selects the files properties. - This feature is helpful when attempting to camouflage the binary process in with other known windows services or files.
Compile Settings: Straight forward options to compile the client binary.
- Hidden mode will install the service in the systems background, suppressing any dialog boxes. This is also known as "Silent installation"
-- Users must agree to IM3 ToS before Builder will compile any Client Binary.

Written By: ȺʁɱªÐą

Main Course Thread

Spoiler (Click to View)
When we discuss R.A.T. safety and security, we are actually taking on the discussion of 2 very different and unique variables. The Remote Administrative Controllers aspect and The Binary Clients considerations.



It is critical to understand the key differences between the machines being discussed, as some security considerations might be ideal for one but counteractive if applied to the other. It is in this discussion we must now apply the considerations from Section 1.
For our purposes we must assume the following:

• The Client Binary and R.A.T. Controller must speak to one another in some fashion for successful communication.
  
• The Client Binary is likely to be in "Hostile Wild Environments"
  
• The Remote Administrative Controller must utilize some fashion of layered protection to keep its true location secretive.
  

Understanding the Hostile Wild
The Internet is a vast expanse of networks of various types of configurations security policies, foot holds, traps and honey pots. It is by these concerns where we treat the Open Internet as a "Wild environment".
It is important to always treat the environment this way when making decisions and determining the considerations required when employing any safety and security strategy.

The primary rule of thumb is almost a paranoia mind set:
"Trust No One, Assume It Can & Will Be Malicious, Take No Unnecessary Risks"

Spoiler (Click to View)
When discussing R.A.T. Health, we are for all intensive purposes speaking about our Binary Client. This is the portion of the Remote Administrative configuration which will be subject to the most scrutiny, have the most liability for security and network related risks. In this section we will examine the A-typical risks associated to Binary installations, the security precautions taken to remove such binaries and counter measures to keep the Binaries healthy and connected to the controller.

Spoiler (Click to View)
When discussing R.A.T. Security, although there is considerations for both the Remote Administrative Controller and the Binary Client. The Primary focus in this aspect take place on the Controllers side of the equation. This is where the application of the core security considerations and precautions will need to take place, and will ultimately determine the Remote Administrators final success when utilizing R.A.T.s



As we continue in to this discussion it should become very apparent there is a face off and a constant battle when discussing Remote Administrative Technologies.
Through the next section we will discuss in detail every aspect for Health and Safety for both Controller and Client ends of the communication.

Written By: ȺʁɱªÐą

Main Course Thread

Spoiler (Click to View)

When we analyze and determine our core security considerations we place focus on the Controlling End. Almost entirely.



In this the Remote Administrator must determine the method of deployment and where the controlling software will reside.

• Will the controller be deployed to a residential network?
  - Example: Remote Admin installs and deploys the controlling software on a LAN based machine they have direct physical access to.
  
• Will the controller be deployed to a remote or server platform?
  - Example: The Remote Administrator elects to utilize a virtual or dedicated server service within the internet to be the designated controller. This is useful for topologies which require consistent and constant communication between the controller and the binary client.
  
• How will connectivity between the Remote Administrator be established with the controlling software?
  - Example: If the Remote Administrator elects to utilize a remote service or server, how will they establish connectivity to the controlling server, and what protocol will be utilized?
  

To best make these determinations. We examine the lessons learned from Section 1.2

The determination of which R.A.T. or Bot will best determine the deployment method. Typical RATs (Such as Luminosity Link, Imminent Monitor, NanoCore) can be deployed to either local or remote locations with relative ease and flexibility.

PHP\Web Based and IRC Based Deployments have more specific requirements, and in general are more suited for remote deployment of the controller software.

Principal Considerations:

• Controlling Machine should always be kept updated with the latest security updates for all installed software, operating system, and security software.
  
• Any\All ports used for services should be configured to "uncommonly used" ports. Unless for explicit rare circumstances, typical communication ports (such as 21, 80, 443, etc) should be avoided to deter network communication conflicts.
  
• Anti viral, Anti-Malware and Firewall policies should be strictly enforced on all controlling machines/servers.
  
• Never give others access or indication where controlling machines or servers are located or accessed. - Unless explicitly trusted.
  

Spoiler (Click to View)

In this portion we will examine the typical Home Residential, the Deployment and the Security policies required for successful Remote Administration.



Now, in this diagram it should become apparent there are numerous layers and levels of protection that reside within even the simplest of Home or Residential configurations. Although these configurations are the A-typical deployment for New Remote Administrators, to Expert level. These what are seemingly the simplest and straight forward implementations where the largest problems are encountered.

Typical Security Boundaries & Limitations That Exist In Residential Networks:

• Internet Service Provider Restrictions
  
• Cable Modem Restrictions or Firewall Policies
  
• Router Firewall and Port Blocking Policies
  
• Computer Security and Firewall Policies
  

Typical Security Risks That Exist When Utilizing Residential Networks:

• Remote Administrators Core\True IP# Being Revealed
  
• Targeted Attacks Being Focused on Remote Administrators Connection
  
• Exploitation of the Controlling Software
  

Deployment to Residential Network

Prerequisites:

1. Create a network mapping of every device which connects the end controlling machine, Make a note of every device make and model, verify its security configuration and default settings. (Modem, Router, etc)
   
2. Contact or verify that your planned Internet Service provider does not automatically "stealth" or block ports by default. Some unfortunately do.
   
3. On the designated controller system, create a list of all security policies, security software, firewall software and Anti viral or Internet Security suites. - This information will become critical for final configuration and deployment of a "Hardened" remote administrative environment.
   

Deployment:

1. DISABLE All Anti Viral \ Anti-Malware and Firewall Software. This includes all Operating System defensive measures as well. (Windows Defender and Windows Firewall)
   
2. Install and Configure Your Chosen R.A.T.
   
3. Utilizing the information gathered from your Prerequisite setup, in specific the networking device make and model information, Port Forward the chosen remote administrative listening port.
   
4. Perform Port Testing Using: http://www.canyouseeme.org to verify the port is actively unblocked, and accepting connections. NOTE: R.A.T. Controller must be actively listening on the designated port before testing to be successful.
   
5. Using Controller Software build 2x Binary Clients - 1x Using the local system loop back hostname of: 127.0.0.1, 1x Using the Real Internet IP# ( http://www.whatismyip.com ).
   
6. Using either a Virtualized Machine or Sandboxie Execute the Binary Builds (local loop back first, uninstall, then real host binary) to test connectivity and ensure proper network communication.
   - If Local loop back 127.0.0.1 works correctly but real host fails, a networking configuration problem exists and requires further troubleshooting before Administrator should proceed.
   
7. Add Exceptions to all Anti Virus and Anti-Malware software for both Controller Binary and a Binary working directory. - For Binary Builds.
   -Allowing your RAT through Windows Firewall
   
8. Enable Security software and firewalls.
   
9. Repeat steps #4-5 in deployment for port testing and binary connectivity.
   

At this point you should have successfully installed, configured and secured the Residential deployment of your Remote Administrative Controller.

Spoiler (Click to View)

When we consider Secure Residential Routing there is 2 avenues to Security.

Firstly, we will discuss why configuration of your Binary clients and use of your Direct IP# is never advisable.
With Remote Administration, it is assumed that the Administrator wishes to utilize stealth and anonymity when utilizing R.A.T. Technologies. If the Home address is utilized the connectivity is easily traced back to the controller.

Secure Routing Example #1 - Best Recommended

Dynamic DNS Enabled Host Address Pointed to a Port Forwarded VPN Network which the controller utilizes for anonymity.



In this example the Remote Administrator has utilized a Virtual Private Network to conceal the true IP# and host address of the R.A.T. Controller. (Including Their Residential and Home address in the process)
This reduces the amount of DNS updates required as the VPN tunnel effectively creates an encrypted data stream between the Binary Clients and the R.A.T. Controller. Including the fact VPN servers are generally statically assigned servers.

Secure Routing Example #2 - LEAST Recommended

Dynamic Enabled DNS Service utilized to point directly to R.A.T. Controllers host address when in use and "Null Pointed" when not in use.



In this example, and the Least Recommended example of Secured Routing for Residential Connectivity. The Remote Administrator utilizes a Dynamic enabled DNS service to point the DNS host address to their IP# when they wish to utilize the Binary clients, and then point to a null IP# address when not utilizing. (Remote Administrator points Dynamic DNS to IP# 127.0.0.1 when not utilizing Controller.)

Why is Example #2 least recommended?
In example #2 we are still directly exposing the Binary Client to the Controllers direct IP#, however we limit the connectivity by null routing when Client connectivity is not required. This can further assist in deterring further analytic of the Binary as it will appear moot in functionality when not in use.

Spoiler (Click to View)

In the deployment to remote services, the process is surprisingly simplified, compared to Residential configurations.



In this example we examine the A-typical configuration of a remotely deployed R.A.T. Controller. The deployment of these configurations vary greatly and is best to determine and create a configuration plan based around the servers specifications and the desired binary to be used. (Some remotely deployed solutions require no controlling software, simply services. Example, IRC Binary Clients)

Deployment:

1. UPDATE All System and Security Software.
   
2. DISABLE All System and Security Software.
   
3. Install and Configure Your Chosen R.A.T. - (If Any)
   
4. Perform Port Testing Using: http://www.canyouseeme.org to verify the port is actively unblocked, and accepting connections. NOTE: R.A.T. Controller must be actively listening on the designated port before testing to be successful.
   
5. Using Controller Software build 2x Binary Clients - 1x Using the local system loop back hostname of: 127.0.0.1, 1x Using the Real Internet IP# ( http://www.whatismyip.com ).
   
6. Using either a Virtualized Machine or Sandboxie Execute the Binary Builds (local loop back first, uninstall, then real host binary) to test connectivity and ensure proper network communication.
   - If Local loop back 127.0.0.1 works correctly but real host fails, a networking configuration problem exists and requires further troubleshooting before Administrator should proceed.
   
7. Add Exceptions to all Anti Virus and Anti-Malware software for both Controller Binary and a Binary working directory. - For Binary Builds.
   
8. Enable Security software and firewalls.
   
9. Retest Port's (Step #4)
   

Written By: ȺʁɱªÐą

Main Course Thread

• Binary Acceptance and Execution
  Spoiler (Click to View)
  
  In this portion it is discussed as 2 possible scenarios for Acceptance and Execution to occur:
  -The end controlling machine user downloads or otherwise accepts the binary installation file to the machine and manually executes it.
  (User is sent the binary and executes it either knowingly or unknowingly.)
  -The binary installation file is "pushed" to the machine and executed.
  (Machine is sent the binary file and told to execute via remote script or user to execute on the machine) - Typical to botnet install shops, or transfer of botnets between controllers.
  Further notation, this classification also includes web deliverable exploits, 0day exploits or other scripted "download and drop" scenarios.
  
  
  
• Binary System Installation
  Spoiler (Click to View)
  
  When the Binary file is executed on the client system the binary goes through a series of "steps" to extract the binary data from the crypted file, drop it on the system, place it where it needs to go in the system and then successfully RUN the application instance.
  
  This being said there are numerous areas where the install process will fail.
  The most likely reasons a Binary might be accepted and Executed but never installs:
  • Windows System Security Stopped the file (Smart screen, windows defender, windows firewall)
    
  • Anti viral software or network appliance detected it the binary
    
  • Anti malware or other system security flagged or detected the binary as a potential threat.
    
  • The system itself is incompatible. (Sending a x64 bit binary to a x32 bit client for example)
    
  • System or Network security policy will not allow execution or installation of software
    
  • User account restrictions
    
  
  Users best counter measures to avoiding a failed install is to use a stable Remote Administrative binary that requires no dependencies. Encode the binary to require Administrative rights to install, and utilize "intelligent" disabling of security precautions.
  
  IE - Many Binary builders or crypters offer Disable Task Manager" or "Disable Anti virus" etc. use of these features can be very effective in installation, however improper or careless use (ie - checking everything off) will cause the end machine to suspect a problem and likely investigate.
  
  
  
• Binary System Integration
  Spoiler (Click to View)
  
  It is at this point the Binary will attempt to "Hook itself" to the system. This is where the advertised Rootkits or System integration.
  This is ALSO the most likely chance for your binary to be detected and removed. Although system integration is a vital part of the Binary install process, it poses the largest risk because in this step\process the binary will now attempt to merge or place itself or load calls in to the systems core run files.
  Example: The system shell, the login service, the browser, etc...
  
  HOWEVER
  It is these actions that are going to likely flag the binary as malicious. All system security software runs what is known as a Heuristic engine (Also coupled with the Real time scanner) This Heuristic Engine constantly monitors and scans critical portions of the operating environment looking for unauthorized or unwanted file modifications (Exactly what our Binary will be attempting to do likely)
  
  As little as there is that can really be done about this (Other than disabling of security software). It is BEST RECOMMENDED: to utilize the binary startup options with care, caution, and above all knowledge of what each function will do on the system and why it could potentially flag the binary as malicious.
  
  Heuristic Engine Definition:
  A Heuristics engine is part of most if not all security software now a days.
  It is for explanation sake a "Database of known system actions or sequences which could potentially be malicious or unwanted"
  - It is in essence the "Generic definition file" for viral or malicious code.
  
  Even though it may not know exactly what the file is, it knows what it is doing is likely unwanted or un-welcomed and will likely block the action outright, or prompt the user to confirm\exclude.
  
  
  
• System O/S Security Measures\Counter Measures
  Spoiler (Click to View)
  
  When speaking about the System O\S Security measures, in general we are speaking of Region Protection, Windows Smart Screen, Windows Defender, and of course Windows Firewall.
  
  It is in these considerations, where we discuss the problems associated to our Binary environments system taking preventative measures. Use of crypters can remove the Region warning (Trusted files vs Files downloaded from the internet) This is typically known as the security prompt as to whether you want to run the binary file obtained from the Internet.
  
  Windows SmartScreen is a fairly new security implementation
  
  
  
  However, has proven to be a very effective tool in prevention of Binary malware, or untrusted files. However, as per Windows 7 and above they are the default settings on Windows install, which most users to not modify.
  The official method to disable SmartScreen as per Microsoft is straight forward, however not recommended controller side.
  
  
  Code

  Open Internet Explorer by clicking the Start button Picture of the Start button. In the search box, type Internet Explorer, and then, in the list of results, click Internet Explorer.

Click the Safety button, point to SmartScreen Filter, and then select Turn Off SmartScreen Filter.

In the Microsoft SmartScreen Filter dialog box, click OK.
  
  Currently, there is no known method to disable Smart Screen from Binary execution, as it prevents the binary from processing before hand.
  
  Windows Defender is another Operating system security measure which has proven to be effective for the more known malware binaries out there. However is relatively ineffective unless the controller is using a very well known binary build such as an old IRC bot, etc.
  
  Windows Firewall, although one of the first of the O\S Security implementations acts as a final guardian to the system before 3rd party external security software comes in to play. It however is the least effective as in its early implementations its constant prompting caused so much user trouble users started blindly accepting the requests, this pattern still exists heavily to this day.
  
  Many crypters and builders can now easily bypass and add rules to the windows firewall without any error or issue.
  
  
  
• Software Security Measures\Counter Measures
  Spoiler (Click to View)
  
  Software security measures are all things Anti viral, Anti malware and software based firewall\Internet security suites. Although readily disabled by some of our simplest crypters and Remote administrative binary builders, one of the highest debatable areas as to whether it is advisable to actually disable such security measures.
  
  The advantages of disabling such instruments is pretty obvious, no risk of the binary being removed.
  HOWEVER the inherited risk associated with such actions is also very straight forward. Most if not all users have become accustomed to listening to their security softwares notifications. Especially when they are told the software has been disabled or corrupted.
  
  This being said, it is MY recommendation to users to not utilize the Disable AV\Anti-malware features, and instead play the Binary Update Game. (Although more work, less likely to raise suspicion)
  
  However, all this being said, is ultimately left to the end controllers decision.
  
  
• Real time Scanning and Heuristics
  Spoiler (Click to View)
  
  Real time scaning and Heuristic Definition Engine are HANDS DOWN the most likely elements to detect, flag and remove a binary install.
  
  But why?
  As noted earlier.
  Heuristic Engine Definition:
  A Heuristics engine is part of most if not all security software now a days.
  It is for explanation sake a "Database of known system actions or sequences which could potentially be malicious or unwanted"
  - It is in essence the "Generic definition file" for viral or malicious code.
  
  This is coupled, married if you will with the element that the real time scan engine runs the Heuristics definitions. And the real time scan runs at all times, unless of course, disabled.
  
  Real time scan is a major threat to RAT operations as even if the binary is completly undetectable by core standard AV definitions, the Heuristics know to look for other elements other than just the binary code elements which traditional AV definitions are composed of. It instead looks for "actions".
  
  Examples of questionable system actions include:
  • "Silent" or backgrounded download and execute commands
    
  • Registry queries
    
  • Constant file searching, especially in protected system zones
    
  • system file modifications
    
  • TCP\IP communications or large piped data requests through an application
    
  • Heavy use of system resources (Crypto mining for example)
    
  
  Although there is no magical solution to avoid these methods of detection given the fact every security software design and their engines vary in functionality, the best recommended practices are:
  • Avoid system file or registry manipulation unless absolutely required.
    
  • No heavy uses of system resources
    
  • Do not tamper with the Security software itself
    
  • Minimize questionable network communications such as large file requests or torrent seeding
    
  
  

(Sep 20, 2015 10:49 PM)ZiLo Wrote:  Please PM me, I'd love to make this some better graphics xD