Our Vision

To give customers the most compelling IT Support experience possible.

Our Mission

Our mission is simple: make technology an asset for your business not a problem.

Our Values

We strive to make technology integrate seamlessly with your business so your business can grow. As your technology partner, when your business grows ours will grow with you, therefore, we will work hand in hand with you to support your growth.

Our Values

We develop relationship that makes a positive difference in our customers Business.

Our Values

We exibit a strong will to win in the marketplace and in every aspect of our Business

Showing posts with label Web Design and Development. Show all posts
Showing posts with label Web Design and Development. Show all posts

Web shells Detectting and Hardening servers against webshell


web shells and its Challenges in detecting 


Web shells can be built using any of several languages that are popular with web applications. Within each language, there are several means of executing arbitrary commands and there are multiple means for arbitrary attacker input. Attackers can also hide instructions in the user agent string or any of the parameters that get passed during a web server/client exchange.
 
When analyzing script, it is important to leverage contextual clues. For example, a scheduled task called “Update Google” that downloads and runs code from a suspicious website should be inspected more closely.

With web shells, analyzing context can be a challenge because the context is not clear until the shell is used. In the following code, the most useful clues are “system” and “cat /etc/passwd”, but they do not appear until the attacker interacts with the web shell:

Another challenge in detecting web shells is uncovering intent. A harmless-seeming script can be malicious depending on intent. But when attackers can upload arbitrary input files in the web directory, then they can upload a full-featured web shell that allows arbitrary code execution—which some very simple web shells do.

These file-upload web shells are simple, lightweight, and easily overlooked because they cannot execute attacker commands on their own. Instead, they can only upload files, such as full-featured web shells, onto web servers. Because of their simplicity, they are difficult to detect and can be dismissed as benign, and so they are often used by attackers for persistence or for early stages of exploitation.

Finally, attackers are known to hide web shells in non-executable file formats, such as media files. Web servers configured to execute server-side code create additional challenges for detecting web shells, because on a web server, a media file is scanned for server-side execution instructions. Attackers can hide web shell scripts within a photo and upload it to a web server. When this file is loaded and analyzed on a workstation, the photo is harmless. But when a web browser asks a server for this file, malicious code executes server side.

These challenges in detecting web shells contribute to their increasing popularity as an attack tool. We constantly monitor how these evasive threats are utilized in cyber attacks, and we continue to improve protections


Web shell: Finding Web Shells

Purpose: Identify web shells (stand-alone|injected)

Data Required : Web server logs (apache, IIS, etc.)

Collection Considerations : Collect from all webservers, and ensure that parameters are collected.

POST data should be collected.

• For apache consider using mod_security or mod_dumpio

• For IIS use Failed Request Tracing / Custom Logging

Analysis Techniques:

Look for parameters passed to image files (e.g., /bad.png?zz=ls

 

Web logs things to notice

    • User-Agent is rare

    • User-Agent is new

    • Domain is rare

    • Domain is new

    • High frequency of http connections

    • URI is same

    • URI varies but length is constant.

    • Domain varies but length is constant

    • Missing referrer

    • Missing or same referrer to multiple uri’s on single dest.

 

 

Endpoint detection strategies:

• Look for creation of processes whose parent is the webserver (e.g., apache, w3wp.exe); these will come from functions like:

○ PHP functions like exec(), shell_exec(), etc.

○ asp(.net) functions like eval(), bind(), etc.)

• Looking for file additions or file changes (if you have a change management process and schedule to easily differentiate 'known good') -- (using something like inotify on linux (or FileSystemWatcher in .NET), to monitor the webroot folder(s) recursively)

 

Other Notable things:

IIS instance (w3wp.exe) running commands like ‘net’, ‘whoami’, ‘dir’, ‘cmd.exe’, or ‘query’, to name a few, is typically a strong early indicator of web shell activity.

 

Look for suspicious process that IIS worker process (w3wp.exe), Apache HTTP server processes (httpd.exe, visualsvnserver.exe), etc. do not typically initiate (e.g., cmd.exe and powershell.exe)

 

Look for suspicious web shell execution, this can identify processes that are associated with remote execution and reconnaissance activity (example: “arp”, “certutil”, “cmd”, “echo”, “ipconfig”, “gpresult”, “hostname”, “net”, “netstat”, “nltest”, “nslookup”, “ping”, “powershell”, “psexec”, “qwinsta”, “route”, “systeminfo”, “tasklist”, “wget”, “whoami”, “wmic”, etc.)

 

lolbas:

    - rundll32.exe

    - dllhost.exe

    tools:

    - net.exe

    - powershell.exe

    - ipconfig.exe

    - CobaltStrike

    - BloodHound

    - nslookup.exe

 

execution:

        - "T1055.012 - Process Injection: Process Hollowing"

    - behavior: RUNDLL32 created ~20 instances of DLLHOST without command-line arguments.

      id: 1669ecb0-3a8a-4858-9efd-23e5c01ad643

      type: Process Created

      cmdLine:

      - C:\\Windows\\System32\\dllhost.exe

      process: C:\\Windows\\System32\\dllhost.exe

      parentProcess: C:\\Windows\\System32\\rundll32.exe

 

Attackers need to execute tools. Look at Windows Event ID's 4688/592. Stack and look for outliers. Group by execution time and user."

 

Hardening servers against web shells

A single web shell allowing attackers to remotely run commands on a server can have far-reaching consequences. With script-based malware, however, everything eventually funnels to a few natural chokepoints, such as cmd.exe, powershell.exe, and cscript.exe. As with most attack vectors, prevention is critical.

Organizations can harden systems against web shell attacks by taking these preventive steps:

  • Identify and remediate vulnerabilities or misconfigurations in web applications and web servers. Use Threat and Vulnerability Management to discover and fix these weaknesses. Deploy the latest security updates as soon as they become available.
 
  • Implement proper segmentation of your perimeter network, such that a compromised web server does not lead to the compromise of the enterprise network.
 
  • Enable antivirus protection on web servers. Turn on cloud-delivered protection to get the latest defenses against new and emerging threats. Users should only be able to upload files in directories that can be scanned by antivirus and configured to not allow server-side scripting or execution.
 
  • Audit and review logs from web servers frequently. Be aware of all systems you expose directly to the internet.
 
  • Utilize the Windows Defender Firewall, intrusion prevention devices, and your network firewall to prevent command-and-control server communication among endpoints whenever possible, limiting lateral movement, as well as other attack activities.
 
  • Check your perimeter firewall and proxy to restrict unnecessary access to services, including access to services through non-standard ports.
 
  • Practice good credential hygiene. Limit the use of accounts with local or domain admin level privileges.

Problem solving tips for helpdesk personnel


Working on a help desk is all about problem solving. Users have problems and look to us for a solution. 

We all know that there are some people who are very good at solving problems and there are those who sometimes struggle. The good ones aren't necessarily more technical, they just have an almost uncanny ability to solve problems which have everyone else stumped.
 
If you are one of those that sometimes struggle, don't worry, it is possible to improve by following some very simple guidelines which we will show you on this site.

On this site we will take you through some of the key steps. The examples are all based on a IT help desk but the principles are universal. 

We present this guide in the form of several numbered steps. This doesn't mean to say that problem solving is a linear process, very often you will need to loop back to an earlier stage.

The Symptoms: It is vital you identify the symptoms. Quite often a user will call with "My computer is not working", but we all know how useless that is ! Here are some questions that are applicable to practically all problems:

1. What is the exact error message?
This maybe obvious, but sometimes it is easy to jump to conclusions based on partial information. If possible, get the user to send you a screen dump (hold down the ALT button, then press the PrtScr buttons, go to e.g. Word, create a new document and select Paste from the Edit menu)

2. What were you doing at the time?
By determining this you can identify which program or which part of the program is causing the problem.

3. Has the error always occurred or just started?
If the program has never worked, then it is possibly a fault with program. If it used to work OK, then you will need to find out at what point in time it stopped working.

4. If it has just started, have you recently installed any other software or made any other changes?
People are very reluctant to admit they have made changes - perhaps they are worried they will get into trouble? So, you will generally find that the answer to this question is "No", but never believe it. The program was working, now it isn't - something must have changed. Bear in mind that the user might not be aware of changes (e.g. many programs and even the operating system may do automatic updates) or they might not realize the significance of some apparently unrelated change.

5. Does it affect all machines or just yours?
If there are other machines that can use the program without problem, then the fault obviously lies with the configuration of this individual's machine.
If every machine has the same problem, it might be that they all have the same configuration problem or it might be a problem with the application's data.

6. In the case of networked programs. if you use the program from a different machine, do you get the same error?
If the error does not appear when you use the same application program from a different machine, then it is likely to be a fault in the configuration of the user's machine.
 

Examine the Evidence

What evidence is relevant? Do you have enough evidence? These are two key questions when problem solving but you aren't going to know the answers to them until you start postulate possible causes and want to test them further.

Experience may sometimes tell you that certain facts are irrelevant. This is good, and will help you concentrate on what you think is relevant, BUT, don't forget about them and keep an open mind.
Your biggest tool for gathering evidence is of course your question and answer sessions with the user, but there are other tools which you can use:

Filemon is a great utility which logs all file activity. Set it running, the go to the problem program and generate the error. Stop Filemmon and look at the log. It generates a great deal of information but it is very easy to see problems.

Event logs: Most operating systems have both application and event logs. Check these to see if anything is relevant.

Confirm everything:  Quite often you have to tease the information out of a user over several question and answer situations. Once you feel that you understand the problem, make sure you confirm it with the user :

"So, as I understand it, if you clck the Update button while creating a new record, the screen crashes with an error "Record must be unique". This was working fine on Friday, no-one else has this problem, and you haven't made any changes to your machine over the weekend. Is that correct?"
If they don't confirm then you must repeat step 1 until you are both happy that you are talking about the same problem.

Research: You know what the symptoms are, you know in what circumstances they appear, now you have to start finding a solution.

Of course, it might be that someone has already done the hard work for you - others may have had, and solved, this problem. There are several sources of information you might try:

Knowledge base : Somewhere, you should have a record of all past problems (and their solutions), otherwise you are going to keep wasting an awful lot of time. This should be in a form that is easily searched. You could use e.g. a spreadsheet, a simple document, a database, or a program designed specifically for the task. As long as it is easy to use.

The Internet : The Internet is a fantastic resource. The only problem is the sheer volume of information. A good search engine is key to getting the best of it. You can almost guarantee that someone, somewhere has had the same problem as your user and if you are lucky, there might be an answer already.

Colleagues: You might try asking your workmates, they may have seen this problem before. Of course, this will disrupt their work so it is not the most efficient use of resources and they will soon get tired of you if you make it a habit. This should only be used as a last resort.

Postulate and test:  By now, you know what the symptoms are and you have done some research on similar problems. You should by now have some theories as to the cause of the problem.

Now you need to test your theories. This usually involves further questioning of the user:
"Your monitor is blank; can you check if there is a green light on the front, bottom right of the monitor?"
 
If there is, then you know there is power to the monitor, but is there a signal?
"Do you have another monitor nearby that you can plug in instead?"
 
If the new monitor works, then it is a problem with the old one. If the problem persists, chase it back up the wire...
"Can you put the original monitor onto a different machine? Does it work Ok there?"
 
If it does, the the fault is with the original PC.
"Is there a green light on the front right of the PC?"
 
If there is, the problem is probably with the PC itself.

Don't assume or jump to conclusions. Take a step by step approach, eliminating possibilities as you go. Sometimes when there are many possible answers you are able to narrow the field considerably by taking an initial broad brush approach. In the above example the first question we asked was "...can you check if there is a green light ...". If the answer was no, then either the monitor wasn't plugged in or there was a power failure. Perhaps a better first question would be "Plug a desk lamp into the same socket - does it work?"

Keep an open mind. You might find yourself going right down one avenue of investigation only to come to a full stop. Don't forget your other theories, go back and test these as well.

Identify the Problem

You know what the symptoms are, you have confirmed everything with the user, had one or more ideas as to the problem and now you have narrowed it down to just one. You must double-check that this you have identified it correctly. There is no point in telling your user to buy a new monitor if all they have to do is wait for the power failure to be restored!
In the ideal world you will be able to devise one test that identifies the problem without doubt.
Of course, in the real world, all you can do is take your best guess, try your solution and hope. The mark of a good support person is how accurate that "guess" is. If you have followed the steps so far, gathered enough evidence, confirmed everything with the user and eliminated other possibilities logically, then your "guess" should be pretty accurate.

Provide a Solution:  This is what the user expects you to do, right? After all, you know what the problem is so fix it.

Most of the time you might have an easy solution. Other times there might not be an immediate fix available - you might need to order a spare part or it might require a new software release. There are even those situations where you don't know what the problem is. In any case, you need to communicate and manage expectations.
 
·         If you have a solution, communicate the fix to the user clearly and ensure they understand.
·         If you don't have an immediate solution, again make sure the user understands this and the likely timeframes. Make sure you schedule an action for yourself to monitor this.
·         If you don't have any solution to the problem, do you have a work-around 

Confirm the Solution: You have told the user how to fix their problem, or you have arranged someone to do it for them. After the fix has gone in, you must confirm with the user that their problem has been solved. You can't assume that the engineer visited, or that the new part worked.
Keep in touch with the user until you know the problem has been resolved.

Communicate and Record : The worst thing for a user is if they believe their problem is not being given attention. They don't care that you have dozens of other users to deal with. That isn't (and shouldn't be) their concern. 

You must manage expectations, if you say "I'll get back to you", their idea of when you should do so might be very different to yours. Instead, say "I'll get back to you before 12:00 tomorrow" and make sure you do, even if it is to tell them that there has been no progress.

Record everything. No one has a perfect memory and no one only ever deals with one thing at a time. You must make a note of conversations, actions, agreements etc.
·         You can easily hand tasks over to other personnel
·         You rarely work on one problem to the exclusion of others until it is completed. So you will be switching back and forth and will need some sort of reminder as to what has happened beforehand.
·         You will build up a knowledge base of problems and solutions for use in the future.
·         If there are recriminations, you have a record of what was done!
In what form you record this is up to you. You could use a document, a simple database, write your own program or use software specifically designed for use by helpdesks.

Sample Ticket Template #01
Which application is the user having issues with?
 - Please include the URL if it is a Web application.
 OR - Please include the folder path if it's a file.
---------------
What is the Incident?  What is the User Experiencing?
/-Type description
What is the Error Message?
Capture message number or description
When did this problem happen?
---------------
What is the Impact to the Business/User?
---------------How many users affected by this one or more / is it happening across the organization?
How urgent is the resolution of this incident?
 (Delete as necessary)
 COB today/ 1 day/ 2 days/ End of week
---------------
Do you have a work around?  Is there any other work you can do, can you use someone else's PC?  Is there another means by which you can get the required task completed?
---------------
What is the name of the users machine? *
 - Shadow user's machine to get this information
Ask user to open command prompt then type hostname
---------------
What is the IP address of the users machine? *
 - Shadow user's machine to get this information
Or Ask user to open command prompt then type ipconfig [windows]/ifconfig [linux]
 Please attach a screenshot of the error
 - Shadow user's machine to get full screenshot
Or ask user to take screen shot and email it to you.

Sample Communication Template #01
Hello 

As a standard procedure, we require approval from your manager so we can fulfill your request.
Please provide this at your earliest convenience (via email if possible).

Thank you
ICT Service Desk Team

Sample Communication Template #02
 
ICT Service Desk Call Back No Response: #01
Dear [         ],

We have attempted to contact you on 1 occasion to resolve your service request, however we have been unsuccessful. 

If you still require assistance for this request, please contact the Service Desk on 00 0000 0000.

Regards
ICT Service Desk Team

Twitter Facebook Favorites More