If you have the time and the spare hardware around, you could install a fresh/blank SME server, do all the updates, then start comparing the two systems.
Another item to check is all running processes listening on ports (then research each item and compare the executable to a known-good system):
# netstat -tulpn
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
tcp 0 0 127.0.0.1:3128 0.0.0.0:* LISTEN 2755/squid
tcp 0 0 192.168.200.2:3128 0.0.0.0:* LISTEN 2755/squid
tcp 0 0 0.0.0.0:25 0.0.0.0:* LISTEN 2460/perl
tcp 0 0 0.0.0.0:2202 0.0.0.0:* LISTEN 2626/sshd
tcp 0 0 127.0.0.1:26 0.0.0.0:* LISTEN 1054/perl
tcp 0 0 0.0.0.0:443 0.0.0.0:* LISTEN 1597/httpd
tcp 0 0 0.0.0.0:636 0.0.0.0:* LISTEN 1991/slapd
tcp 0 0 127.0.0.1:4190 0.0.0.0:* LISTEN 2318/dovecot
tcp 0 0 127.0.0.1:20000 0.0.0.0:* LISTEN 14599/sogod
tcp 0 0 0.0.0.0:993 0.0.0.0:* LISTEN 2318/dovecot
tcp 0 0 0.0.0.0:515 0.0.0.0:* LISTEN 2253/lpd
tcp 0 0 0.0.0.0:995 0.0.0.0:* LISTEN 2215/tcpsvd
tcp 0 0 0.0.0.0:389 0.0.0.0:* LISTEN 1991/slapd
tcp 0 0 0.0.0.0:9001 0.0.0.0:* LISTEN 3164/node
tcp 0 0 0.0.0.0:3306 0.0.0.0:* LISTEN 3171/mysqld
tcp 0 0 127.0.0.1:139 0.0.0.0:* LISTEN 2784/smbd
tcp 0 0 192.168.200.2:139 0.0.0.0:* LISTEN 2784/smbd
tcp 0 0 0.0.0.0:8843 0.0.0.0:* LISTEN 1597/httpd
tcp 0 0 127.0.0.1:11211 0.0.0.0:* LISTEN 2172/memcached
tcp 0 0 0.0.0.0:110 0.0.0.0:* LISTEN 2201/tcpsvd
tcp 0 0 127.0.0.1:783 0.0.0.0:* LISTEN 2736/perl
tcp 0 0 127.0.0.1:143 0.0.0.0:* LISTEN 2318/dovecot
tcp 0 0 0.0.0.0:80 0.0.0.0:* LISTEN 1597/httpd
tcp 0 0 0.0.0.0:465 0.0.0.0:* LISTEN 2606/perl
tcp 0 0 127.0.0.1:980 0.0.0.0:* LISTEN 2645/httpd-admin
tcp 0 0 0.0.0.0:21 0.0.0.0:* LISTEN 2441/tcpsvd
tcp 0 0 127.0.0.2:53 0.0.0.0:* LISTEN 2168/dnscache
tcp 0 0 192.168.200.2:53 0.0.0.0:* LISTEN 2151/dnscache
udp 0 0 0.0.0.0:67 0.0.0.0:* 3416/dhcpd
udp 0 0 127.0.0.1:11211 0.0.0.0:* 2172/memcached
udp 0 0 0.0.0.0:59895 0.0.0.0:* 2755/squid
udp 0 0 192.168.200.2:123 0.0.0.0:* 2387/ntpd
udp 0 0 127.0.0.1:123 0.0.0.0:* 2387/ntpd
udp 0 0 0.0.0.0:123 0.0.0.0:* 2387/ntpd
udp 0 0 192.168.200.255:137 0.0.0.0:* 2774/nmbd
udp 0 0 192.168.200.2:137 0.0.0.0:* 2774/nmbd
udp 0 0 0.0.0.0:137 0.0.0.0:* 2774/nmbd
udp 0 0 192.168.200.255:138 0.0.0.0:* 2774/nmbd
udp 0 0 192.168.200.2:138 0.0.0.0:* 2774/nmbd
udp 0 0 0.0.0.0:138 0.0.0.0:* 2774/nmbd
udp 0 0 0.0.0.0:1812 0.0.0.0:* 2704/radiusd
udp 0 0 0.0.0.0:1813 0.0.0.0:* 2704/radiusd
udp 0 0 127.0.0.1:53 0.0.0.0:* 2298/tinydns
udp 0 0 127.0.0.2:53 0.0.0.0:* 2168/dnscache
udp 0 0 192.168.200.2:53 0.0.0.0:* 2151/dnscache
udp 0 0 :::123 :::* 2387/ntpd
If you've truly been compromised, you also need to locate and examine anything that might run a program on a schedule -- cron, startup scripts, service definitions, php code for all web apps (owncloud has a scheduler option described as 'run when pages are reloaded', IIRC).
Any services accessible from offsite must be thoroughly researched and vetted.
For example:
If ssh is accessible from offsite, is there now an unexplained entry in <user>/.ssh/authorized_keys for any user (bearing in mind that it is possible to have ssh use a different filename for authorized_keys)?
Are there any unexplained user accounts in /etc/passwd or in your ldap?
The original linux hack (from a book I read in the early 90's) was to replace the login executable with either a wrapper or compromised version that saved usernames and passwords for every login for later recovery.
Every executable that is able to communicate over a network - inbound or outbound - might be compromized either in the file itself or in its configuration in a way that could give the attacker renewed/future access to your server...
And, to really light up your day -- if your server has truly been hacked, the attacker may have compromised one or more other systems or devices on your LAN, which would then let them use that system to regain access to the server. If the SME server is your router and dns they could also have snooped credentials out of your browser sessions with offsite servers and services...