Syspeace is a HIPS (Host Intrusion Prevention System) that monitors failed logins attempts on for instance Remote Desktop Servers, Exchange Server, SQL Servers, Winlogon events on Windows Servers from Windows Server 2003 and more and blocks, tracks and reports the attacker based on customazible rules
Sometimes though, the event (Eventid 4625 or eventid 529 and a few other security events we monitor) doesn’t actually contain the source IP address thus leaving Syspeace with nothing to block.
If there’s no IP address to block, it can’t be put into to the Windows Frewall Syspeace rules and the bruteforce attack can continue.
This essentially happens when you switch from RDP layer security to using a certificate.
An article on Stackoverflow might be pointing to a solution though
Here’s a warning though!
If you’re using the RD WEB also to publish Remote Resources.
For some reason , your MAC OS clients will stop recieving Remote Resources since it seems to run on NTLM version 1 (and I would guess Android and XP too )
Also scanners may stop working locally if they need to write files to a newtorks share
I tried a lab with this and when seting the – Network security: Restrict NTLM: Incoming NTLM traffic — Deny all accounts , the remote resources can’t be refreshed.
There are a few warnings when changing this setting and you should investigate if there are applications or services in your server environment that are dependent on LM or NTLM (v1).
I’ve changed the setting on a number of servers and haven’t seen anything stop working but still you should investigate before changing.
Syspeace automatically blocks attacks that occur according to the rules.
The default rule is that if an intruder fails to login more than 5 times within 30 minutes, the intruders IP address is blocked, tracked and reported for 2 hours and simply is denied any access to the server.
A new trend though has emerged and that is for bruteforce attackers to ”slowgrind” through servers, trying to stay ”under the radar” really from IDS/IPS HIPS/HIDS such as Syspeace.
They’ve got thousands and thousands of computers at their disposal so they’ll basically just try a few times at each server and then move on to next one in the IP range or geographical location hoping not to trigger any alarms or hacker countermeasures in place.
An easy way to battle this is actually simply to change the default rule in Syspeace from the time windows of 30 minutes to for example 5 days.
This way , I’m pretty sure you’ll see there are quite a few attackers that only tried 2 or three times a couple of days ago and they’re back again but still only trying only a few times.
With the ”5 day” windows, you’ll catch and block those attacks too.
Here’s actually a brilliant example of an attack blocked, using a 4 day window.
Blocked address 126.96.36.199() [China] 2014-08-11 15:06:00
Rule used (Winlogon):
Name: Catch All Login
Trigger window: 4.00:30:00
Lockout time: 02:00:00
Previous observations of this IP address:
2014-08-11 13:05:51 aksabadministrator
2014-08-10 22:06:48 aksabadministrator
2014-08-10 06:39:12 aksabadministrator
2014-08-09 15:39:52 aksabadministrator
2014-08-09 00:32:05 aksabadministrator
Syspeace has blocked more than 3 285 300 intrusion attempts against Windows Servers worldwide so far.
What is a brute force attack or dictionary attack really and how would Syspeace help?
Essentially it is someone who is trying to guess the right combination of username and password to gain access into your serveers for example a Microsoft Exchange Serve and the OWA (Outlook Web Access), Terminal Server/RDS (Remote Desktop Server), Sharepoint, SQL Server, Citrix and so on.
The attacker uses automated software to try to guess the right combination to be able to login and steal data or to elevate their rights. One attack can render in thousands of login attempts, it can go on for hours or days and it is a heavy load for the server to handle that in regards of CPU, RAM, network traffic and so on.
Each login request has to validated and checked if it is legitimate or not.
A comparison of a brute force attack and the real world be be this (this is an excerpt from the Syspeace website)
”Imagine that your company has a physical facility. If someone repeatedly tries to gain access with a fake key or invalid key card, you would expect that your security guards would notice and not let the intruder through”
Aren’t there builtin protection into Windows Server against these attacks ?
In short. No.
The only built in mechanisms in Windows Servers are basically the ability to enforce strong passwords and to enable account lockout.
To enable strong passwords is a good thing, even if you’re running an intrusion prevention software for Windows like Syspeace.
If you have easy-to-guess passwords, it won’t really matter what protection you’re sunning since if a login is valid, no software would block it anyway. A valid username and password is always a valid login. So, please ensure you require users to use strong and complex passwords and allow for Syspeace to capture the attack.
The second method , ie. account lockout, might actaully do you more harm than good and here’s why.
If the system you’re protecting is for instance an Exchange Server or an RDS Server and it is probably facing he Intenet to provide service for your users or customers. To figure out a username doesn’t have to be that complicated fo an attacker. They’ll first try to understand the email policy naming convention, scavenge the Internet for metadata and the simply start trying to login using the email address as the username (since this is quite often a valid login name) and try guess to guess the password.
If you’ve enabled the Account Lockout Policy the affected users accounts will be constantly locked since the attacker will automate the attack and try thousands of time for each user they know are in the system.
If you’ve been hit with an attack and it is just from a single IP address, you’d probably just block it in the Windows Firewall (or the external firewall) and unlock the affected users accounts and that’s it. Hopefully you’d also report it.
Now, what if the attack is actually done from hundreds or thousands of computers at the same time ? Blocking them manually isn’t really an option is it ?
One simple and quick solution is to download the fully functional trial of Syspeace , install it and have Syspeace block, track and report the attack.
How can Syspeace help as an Intrusion Prevention for Windows Servers and do I set it up?
The idea behind Syspeace is the ease of use and independence from other software and appliances and also not to enforce a change in your network or infrastructure.
Some systems require you to change your entire infrastructure and put for instance a high performing proxy appliance or server in front of the network. Other systems are bundled with antivruses and other systems, requiring you use consultants and experts to get the systems running.
Syspeace is simply installed on the servers you want to protect. The installation process takes about 4-5 minutes maximum and that’s it. You’re done. The server is protected against brute force attacks. Out of the box.
Th Syspeace GUI is easy to understand and easy to manage. You don’t have to be a security expert to manage Syspeace.
If you want to move a Syspeace license from one server to antoher , that’s also easily done thanks to the floating licensing model within Syspeace. The length of the license can also vary so you’re not forced into buying a 1 year license if you don’t want to . You can a license fo 1 month. or 3 months, Whatever suits your needs.
The pricing of Syspeace is more or less equivavlent to an antivirus and it is a per-server based licensing so it’s not based up on the number of users you’re servicing. 1 license, 1 server. That’s it.
These are some of the features included in Syspeace
Secure login attempts on Windows server
The Windows server is secured by watching the result of the Logon process. If multiple logon attempts fails, actions can be taken. This works on Windows Server 2003 and on and is also automatically protection for Remote Desktop Services, Sharepoint, Exchange OWA, Citrix and basically anthing that renders an eventid of 4635 or eventid 529 (we do monitor more events also)
Secure login to Exchange Serevr SMTP connectors
The Exchange server is usually exposed by the OWA web site that is a part of Exchange. Syspeace not only protects the OWA but also logon attempts made by connectors.
Secure login to SQL Server
Many SQL-server installations expose a logon-possibility either by AD-integration or by logon by using SQL Authentication. Syspeace protects both methods
Multiple customizable rules
Syspeace can be tailored to fit your specific needs by customizing the rule-base. The rules are executed in real-time on all successful and unsuccessful logon attempts and appropriate measures are taken.
Send mail when a block is done
Whenever a block (rule) is entered in the firewall, you have the option to be notified by mail.
Send daily mail with aggregated intrusion information both as plain text and attached CSV file
Each day, there is a summary created that you can have mailed to you or the people that you see will benefit from it.
Send weekly mail with aggregated intrusion information both as plain text and attached CSV file
If the daily summary is too granular, a weekly summary is also available in the same way.
Uses local whitelist
Some computers should never be blocked in your environment. These computers can be listed in a local Whitelist so that Syspeace will never block these IP addresses.
Uses local blacklist
The local blacklist is a opportunity to force a block to a specific set of computers that you never want to connect to your server.
Uses global blacklist
Syspeace comes with a Global Blacklist. This list is maintained by Syspeace central servers and distributed once a day to your Syspeace installation. The Global Blacklist contains computers that have tried to break the security on many other sites that run Syspeace.
Searchable log of login/intrusion attempts
Syspeace have the ability to in a very easy way present information about who is attacking you and when it happened. The data is searchable, aggregated and presented in a matter of a few simple clicks.
View information on why a block was made
A block may be initiated from many different sources. Together with the block is also information stored about the origin. It is always possible to back track a block.
Access report to quickly find related information in the attempt log
The Access report takes the reporting to a new level. Here, it is possible to further aggregate and investigate what happens to your server.
Updates are free and new features are included. We’ve also released the ability write your own Syspeace Detectors thurough the Syspeace API to protect for instance a webapplication or write a special detector for your Windows applications.
Who should use Syspeace then ?
Syspeace isn’t targeted at any special types of environments or companies, we believe that Syspeace is a natural part to use for any server administrator, regardless of if you’re a Cloud Service provider or managing you own servers or if you’re an outsourcing company, hosting company or even if the servers are physical or virtual.
Syspeace can help in any scenario so the short answer is, any system admininstrator managing a Windows Server from Windows Server 2003 and on really.
It is not a ”silver bullet” for security but a piece of the security puzzle we believ you’ll need to ensure the protection of your users or customers and it solves a problem easily that no one hasn’t really been able to handle earlier.
If yuu’re up for reading more about intrusion prevention for Windows Servers, please have a look at the earlier articles written here on this blog or have simply go to the Syspeace website for more information and download a trial.
After installing Syspeace , the tech guys started getting notifications that their Exchange Server was trying to login to another server and it was rejected. There was no reason for this server to do so whatsoever and it had not been noticed earlier so it’s hard to say when it actually started.
After disabling the whitelist for the LAN at the customer site they started getting mail notifications that every workstation on their LAN was actually trying to login to various servers using various usernames and password, hence a brute force attack/dictionary attack from the inside.
Most likely a trojan has been planted somewhere and it has infected the rest.
This is a fairly simple example of how Syspeace can actually reveal a security breach a customer wasn’t even aware of had occured.
It is totally up to any customer to use whitelists for the LAN but as a precaution, I personnally wouldn’t recommend it since it acutally gives you a great heads up that something has happened if a computer or multiple computers suddenly starts to try and login to servers they’re not supposed to.
As a system administrator, you get the chance to get attack automatically blocked, logged, traced and reported and you can have a closer at the computer responsible for the attack or have a word the user to see what’s going on.
You can even create extensive reports on all activity originating from that user or computer using the Access Reports section in Syspeace to get a more clear view on how long it’s been trying and so on.
Since Syspeace automatically protects failed logins using Winlogon authentication, your Windows servers are also protected from computers/users trying to use the ”net use” or ”map network drive” with invalid logon credentials trying to acces shares they’re not supposed to.
If you don’t have processes in place for scanning logs, saving them and monitoring every login activity, it will become grusome task to even know if there’s something going on at all. You simply won’t have the tools to do so.
Have your own servers run the fully functional Syspeace free trial and see if you get any unexpected login failures from the internal network and from Internet.
You might be surprised.
Provides Windows Server 2003 support for SQL Server-based blocking, a better interface for viewing current and possible blocks and improves behavior when Syspeace servers are unreachable. For more information about all improvements, see the full release notes.
Syspeace now supports SQL Server-based blocking on Windows Server 2003.
The list in the status window has been replaced with a new list, containing a summary of current blocks and suspected upcoming blocks.
Suspected upcoming blocks refers to observed failed logins that have yet to trigger a rule.
For current blocks, the observed failed logins that triggered a rule are shown.
Single IP address entries show the geographical location if available.
The list can be filtered in the bottom left of the window. Current blocks based on observations are always shown. Blacklisted IP addresses can be shown or hidden.
IP addresses can directly be added to the local blacklist, removed from the local blacklist and added to the whitelist from the info pane directly. Current blocks can also be forgiven (the block is removed and the IP address’ failed login record starts over).
When the Syspeace client is started and there are Windows login rules enabled, Syspeace will check to make sure that the current security policy will allow logon failure audit events to be produced and warn if this is not the case. Without this properly set, Syspeace will not be able to detect Windows login failures.
The description for each entry in the local blacklist and whitelist can now be changed without having to recreate the entry.
Duplicate entries for IP addresses can no longer be added in the local blacklist and whitelist.
Syspeace’s behavior and stability when the Syspeace backend and license server is unreachable is improved.
Changes to bring the size of the local database down.
Fixed a bug preventing the removal of the ban corresponding to the last blacklist entry.
Improved migration from Syspeace 1.1.*.
This is actually a repost on a fairly well read blogpost but I thought I’d share it with you again.
Intro on brute force / dictionary attack prevention tactics and some common misconceptions
Protection from brute force attempts on Windows servers has always been a nightmare and would continue to be so if not .. Yes, I admit, I will come up with a solution further down.
Most system administrators with selfrespect start off with the best of intentions to actually keep track of brute force / dictianary attack attempts but eventually give up because of the sheer number of attacks that occur daily.
Others, unfortunately, believe that a firewall takes care of the problem which it doesn’t or that an account lockout policy is the answer. Neither of them is and I’ll show you why.
The firewall approach:
Think about it. What does a firewall actually do ? The role of the firewall is to block traffic on unwanted ports and to drop portscans and variuos SYN FLOOD attacks. That’s about it. A firewall is basically a harsch doorman deciding who gets in to speak with the guys on the inside and who doesn’t.
If an attacker actually connects on a valid port , the traffic is redirected/port forwarded to the server in question let’s say the webmail interface of a Microsoft Exchange Server or a Microsoft Windows Terminal Server or a Citrix Server. Once the attacker is there, the actual logon request is handled by the server,not the firewall. The logon process is managed by the Windows Authentication process (which in turn may be validated against Active Directoy or a local user database using SAM). The firewall is already out of the picture really since it has no connection with the Windws server apart from the TCP connection and keeping it alive really. They don’t communicate the result of the logon process between eachother.
Also, a changing of from standard ports won’t help you much, will it ? The logon process is still managed by the Windows Server although you will get rid a of a lot of portscans and ”lazy background, script kiddie attempts” if you’re using non standard ports. Basically you get rid of the script kiddies but the problem isn’t solved, the traffic is still redirected/port forwarded to the server that does the actual authentication.
Using for instance a Remote Desktop Gateway won’t handle the problem either. Using a RDP Gateway minimizes the attack surface, yes, but it is still reachable and the user logons still have to be validated. The problem is with any server that services logon request basically, regardless of on what ports and how they get there. That is Microsoft Windows server, Exchange Server, Citrix, Sharepoint, CRM , Terminal server and so on . The list can probably go on and on.
There’s also the risk of stuff stops working each time you apply some updates or patches to your Windows Servers if you start changing standard ports or standard configurations. It’s happened to me a few times and it’s not that amusing to be honest when you’ve got 1000 users not being able to log in beacuse you’ve just done your job and patched the servers to keep peolpe datas safe. Trust me, that’s not a good Monday morning.
The VPN approach:
Yes. That’s a safer approach but also here we do have some issues. First of all, it’s not that easy to keep track of VPN certificates, to set all of it up and manage all the licensing costs (that can be quite significant really ) and (sometimes costly) hardware you need to have in place. Historically there has also always been performance issues with most VPN solutions since all traffic is directed through one or a few VPN servers / connectors. Some of them also charge you for the bandwidth you want it to be able to use for VPN connections or charge you for the number of simultaneous VPN connections, A VPN solution can be quite costly as an initial investment and taking into account all of the administration involved in it.
You also probably won’t be demanding your users to have a VPN connection to the Microsoft Exchange OWA etiher snce the whole idea of the OWA i that it’s supposed to easy to reach from anywhere. I know there are some companies actually requiring VPN even for OWA and that’s just fine I guess but the more we’re moving our data and applications to cloud services, this hassle with different VPNs and stuff will eventually be fading into the dark corners of the Internet (that’s my personal belief anyways). The thing is that your users don’t want to be tied down by complicated VPN clients and stuff, users nowdays are used ”stuff just working” and it has to be easy and intuititive for them. The days of the ”System Administrators from Hell” implementing all kinds of complex solutions to keep stuff secure and forcing users to having very specific and complex ways of accessing data are over. They were good times, good times but they’re over. Deal with it.
The IDS/IPS approach:
Using a centralized IDS/IPS This is a more efficient method, yes. The downside is, most of these systems require you to change your infrastructure and get specific, costly hardware, licenses and costly consultants to get it up and running. And someone needs to monitor it, take care of it and so on. There are parllells to the VPN approach here although an IDS/IPS does a while lot more such as examines all the network traffic, examines it for malicious code and so on. I’m not sure actually if an IDS/IPS can communicate with the Windows Server Authentication Process so I’ll actually won’t say anything about that. I would presume they can, otherwise I fail to see the point (from the brute force logon prespective, that is) and you’d still need to handle the logon attempt on the Windows server.
The Account Lockout Policy approach:
The acccount lockout method is also flawed due to the fact that an attacker can quite easily cause a DOS (Denial of Service) simply by hammering your server with invalid logon request but with valid usernames, thus rendering the accounts unusable for the valid users. Basically, all he (or she) needs to know is the user logon name and in many system , it’s not tha hard to guess (try the companynameusername or the mail address for the user since it’s quite often also a valid logon name if you have a look at the properties of the user in Active Directory Users and Group snap-in)
The Cloud Computing approach
We are shifting more and more of our data and applications into various Cloud Services (like it or not but, it’s a fact and you know it). This way we do get rid of some of these problems on our own servers and hopefully, your Cloud Service provider actually has a plan for these scenarios and has the necessary surveillance software and systems in place. If you’re using a Cloud Computing platform based on Windows Servers, you should actually ask your provider how they handle brute force attempts on their servers. Most likely they will give you one or more of the scenarios described above and, as I’ve showed you, they are not adequate to handle the task at hand. They’re just not up for the job. Feel free to ask your own provider and see what answer you get. My guess is .. mumbo jumbo but basically , they don’t have anything in place really, more or less.
You could even try logging into you own account with your own username but the wrong password loads of times and see what happens. Will it be locked out? Will your machine be locked out? How does your Cloud Srvice Provider respond and are you informed in any way that an intrsuion attempt has been made using your account ? How many times can anypne try to access your account without you being notifed of it? And from where are they trying to get to your data and why?
Personally I know of only one Cloud Service Provider that has also taken these questions into account and that’s Red Cloud IT in Sweden.
Is there a solution then?
Yeah. I told you so in the beginning and even if you choose not to use what I suggest, I highly recommend that you start thinking about these things properly because these problems will accelerate in the future. Just take a look at all the hacktivism with DDOS attacks going on out there. It’s just a start because the Internet is still young.
First of all, and this is extremely important you realize, , it doesn’t matter if you hosting your own servers or if you’re using VPS (Virtual Private Servers) hosted somewhere else or even if you’re a Cloud Service Provider. The basic principal stands: if you are providing any kind of service to users using the Windows Authentication mechanism you should be reading this and hopefully my point has come across.
If you’re having brute force attacks on your Windows systems today and I’m pretty sure you do (just turn on logon auditing and I’m sure you’ll see you have more than you actually thought you did, *for some odd reason this is NOT turned on by defaut in Windows*) there’s a few things you should be doing (that I’m guessing you’re not beacuse you’re not a cyborg and you need to sleep, meet your friends and family and actually be doing something productive during your work hours). On the other hand, if you are doing all of these things I’m guessing you have quite a large IT staff with a lot of time on their hands. Good for you. Call me and I’ll apply for a position.
First of all. Block the attack.
You need the attack to stop! Instantly. This is of course your first priority That’s basically blocking it in the firewall, either in the local Windows firewall or the external one, it’s actually up to you which way is the easiest one. The reason is that you don’t want to be wasting CPU and RAM and bandwidth on these people (or botnets) and of course, you don’t want them to actually succeed in logging on (should you have a lousy password policy in place ) or even them disguising a real intrusion attempt behind a DDOS attack to fill your logfiles and hide themselves in there. (Yes, it’s not an uncommon method). There’s also quite a few reports of DDOS attacks being used to disguise the actual reason for it which is to find out what security measures are in places for future reference. The ”know your enemy principal”.
Second. Trace the attack. From where did it come?
Second , you need to find out from where the attack originated and what username was used. This is because you want to know if it is a competitor trying to hack you and access your corporate data or if you find yourself in the interesting position of your own username trying to login from sunny Brazil and you’re just not in Brazil (although you’d love to be) . You’re in Chicago looking at winter. Somethng’s up.
You also want to see if it’s a former employee trying to log on and so on .. This is stuff you need to know and keep track of since there may be legal issues involved further down the line.
Points one and two , you want to be handled in real time. There’s no use for you to find out two days after the attack that something actually happened. You want it stopped, reported and handled as it happens.
The legal stuff.
Third, you need to decide what to do with your information. Should it be handed over to the legal departement, your boss, the police or is it just ”nothing” and can be discarded ?
So. ”What would you suggest as a solution then” ?
The easiest and most cost efficient way to handle brute force attacks on Windows server is to have an automated sysem to block, track and report each attack and that’s where Syspeace comes into play.
Syspeace is a locally installed Windows service, thus using a minimum of system resources, that monitors the server for unwanted logon attempts and blocks the intruders in real time in the local firewall based on the rules you’ve set up. For instance ”if this IP address has failed logging on 20 times during the last 30 minutes then block it completely for 5 hours and send me an email about it”
This means that you can for instance set up a blocking rule that is you ”Account lockout policy – 1” in your rules and that way simply blocking the bruteforce attack but not locking your users accounts and causing them unecesseray disruption.
Since Syspeace monitors the Windows Authentication logon oprocess, it doesn’t matter what firewall your using or what ports you’re using, the monitoring and blocking is done where the actual login attempts is made and therefore caught and handled automatically.
Once the intruders IP address is blocked, it’s blocked on ALL ports from that server which means that if you have other services also running on it (like FTP or well.. anyhting really) those ports and services are also protected instantly from the attacker. Not giving them the chance to find other ways of gaining access to that server through exploits.
A few other features in Syspeace
A few other nice features with Syspeace is for instance the GBL (Global BlackLlist) where every Syspeace installation around the world , reports each attack to a databse where they are examined and weighed and , if deemed ”meneace to Internet and all of mankind” the database is then propagated to all other Syspeace installations. In this way, you’re preemptively protected when the bad guys come knocking on your door. So far , there has been over 200 000 brute force attcks blocked by Syspeace worldwide (and that’s just since mid July 2012) and some of them have made it to the GBL. Lucky them.
Of course there are white lists and stuff, giving you the ability to have your customers or internal users keep hammering you servers all day long if they (and you) want without being blocked out.
There’s also the Attack Cintrol section that gives you the ability to sort out information about successful and failed logons, findind the ones that are trying to stay under the radar, viewing reports.
You get daily and weekly reports email to you and each attack is also mailed to you with detailed but easy to understand information from where the attack originated including country, what username was used and how many times they actually tried to hack or overload you. This gives you the ability to quickly see of it’s something you should be taking care of or just carry on with your working day and leave it be with a smile on your face.
The GUI is easy to use (and there’s an even easier coming up in the next version) so there’s no need to hire costly consultants to be up & running or start using various scripts and change parameters in them to suite you needs and hope for the best and hope they don’t hang your servers.
Syspeace also protects the Microsoft Exchange Server Connectors from being attacked.
The licensing is not steep, I’d even dare say cheap and it’s extremely flexible.
As an example. If you buy yourself a new server today (evereybody loves new toys ) , you install Syspeace on it and then you get yourself a second server in 4 months. You can easily align the licensing renewal dates for both servers , not having to keep track of licensing renewals scattered over the entire year. If you’re up for , you could even byt yourslef just a one months license. Or a week. I’s up to you and what needs you have.
Download a free trial and see for yourself.
We know it works and so does all of the people around the world who are already running it.
Most Syspeace users have the software in place to protect them from mainly from external threats from the Internet such as hacking attempts via bruteforce attacks and dictionary attacks.
Quite often, the internal netowrk ranges are excluded in the local whitelist by sysadmins , thus never blocking anything from those IP addresses or network ranges.
Some of our customers though have also discovered Syspeace to be an excellent tool to keep track of failed internal logins and those might actualy be important to keep track of.
If you’re not keeping track of internal failed login attempts, it might be hard to spot for instance a virus/trojan infected PC on your network that tries to login to every PC and server that is available or if a user is trying to access servers or assets they’re not supposed to. With Syspeace, the attack is automatically blocked, reported and and the sysadmin is alerted that something’s going on.
There can be downsides to not excluding internal IP ranges since there is a risk of for instance blocking a server from communicating with another but if you’re vigilant and think these things through, it’s mostly an administrative task to remember that yov’ve got Syspeace when you’ve changeed an administrators password or whatever.
Creating reports on user logins
Another great feature of Syspeace is the reporting section that enables for sysadmins to create reports and staistics about user logins such as when, from where and even hof often from that locationc they’ve actually been logged in.
For instance, if a user claims to have been working from home in July, it’s quite easy for a sysadmin to actually verify this using the Access Reports section to create .csv files with statistics.
Now, if the IP address for instance originates from Spain and your company is located only in Sweden…
If you’re using a Windows Server-based Cloud Service for instance, it might be difficult for you to get hold of such information, even if you ask for it.
Howerver, if your cloud Service provider is running Syspeace to protect you and other customers it’s a walk in the park for the provider to get you that infomation if you need it for some reason.
Syspeace stores failed and successful login in a local database so even the Windows securiy eventlog is cleared , the information can still be obtained by Syspeace.
Download a free, fully functional trial at http://www.syspeace.com and have your Windows, Citrix, RDS, Sharepoint, Exchange, OWA, RDWEB, SQL servers and more instantly protected from hacking attempts.