3 ms·
> yes, in fact it looks like they only spend 3-4 hours per day on corp infrastructure, time for a chat. Depending on the role, this is a poor metric. I'm sayin
by jstarfish 3y ago
> yes, in fact it looks like they only spend 3-4 hours per day on corp infrastructure, time for a chat.
Depending on the role, this is a poor metric. I'm saying this as someone who investigates this sort of behavior for a living.
Even a developer-- surely they're actively on the computer all day, right? Except extended whiteboard time, meetings, huddles, etc. all reduce that visible footprint.
> What I am after is a dashboard that I can pull up when someone is suspected of overemployment because of a performance issue.
You have the right approach-- what I'm about to share are a few queries I use to collect intelligence--not evidence--of such behavior. The two are very much not the same.
If you have Defender ATP (or maybe Sentinel?) you could look at this from a few angles. My own little trade secret is looking at the intersection of labor law and login counts.
Start with mouse jigglers. This query catches USB hardware jigglers that have become popular on Amazon and AliExpress. The best jiggler is an optical mouse on the face of an analog clock-- impossible to detect without cursor tracking.
Exceptions: This works for now, but don't trust it long-term since it's easy to spoof the IDs once vendors/users catch on.
```
DeviceEvents
| extend ClassName = parse_json(AdditionalFields).ClassName
| extend VendorIds = parse_json(AdditionalFields).VendorIds
| extend DeviceDescription = tostring(parse_json(AdditionalFields).DeviceDescription)
| mv-expand VendorIds
| where VendorIds contains '\\vid_' and VendorIds contains '&pid_'
| where VendorIds !contains '&rev_' and VendorIds !contains "&mi_"
| where VendorIds contains "vid_0e90"
| where Timestamp >= ago(90d)
| where ActionType startswith "pnp"
| summarize min(Timestamp), max(Timestamp), count(VendorIds) by DeviceId, DeviceName, tostring(ClassName), tostring(VendorIds), DeviceDescription
```
There are software mouse jigglers too, same caveat as above, and I'm sure there's a million more I don't know about but this one is currently yielding 300+ results for me as-is:
```
DeviceProcessEvents
| where FileName contains "jiggle" or (FileName contains "mouse" and FileName contains "move") or FileName contains "caffeine"
or FileName contains "amphetamine"
| where Timestamp >= ago(90d)
| summarize by DeviceId, DeviceName, FileName, ProcessCommandLine, InitiatingProcessAccountName
```
Then you want to look at login counts. My nutshell theory is that labor law mandates employees take 2-3 breaks a day, and per policy (and PCI and NIST and others) employees are supposed to be locking their workstation or seeing it lock itself every time they leave their desk. Ergo, we should see 4-5 logins at a minimum per employee per day (once in morning, once at lunch, and 2-3+ breaks later). WFH is no excuse to not lock the workstation.
Exceptions: You'll come across engineers who eat nothing but Adderall and piss in bottles at their desk. You'll also come across clowns who claim that they're RDPing into their work machine from a personal device; this is verifiable with a separate query but IME these people are usually problematic for other reasons and the RDP excuse is a red flag for OE in itself ("...b-b-but my big screen" is the usual counter). For some reason our network admin's account has 1 login in the last 90 days but I know for a fact he's working; I assume he's using a root account I don't know about on some jumpbox that I can't reach. You'll usually find executives topping the list of lowest login count for reasons other posters have enumerated. Be aware that this will also net people on leave, vacation, holidays, extended illness, etc.
```
DeviceLogonEvents
| where LogonType == "Interactive"
| where ActionType contains "Success"
| where AccountName !contains "$" and AccountName !contains "-" and AccountName != ""
| where Timestamp >= ago(90d)
| summarize count(ReportId) by AccountName
| order by count_ReportId asc
```
Use yourself as a baseline; you'll probably have hundreds of logins while working a varied schedule with a reasonable amount of AFK time. If your own normal working behavior has a score of n, anybody <n provides probable cause for scrutiny.
Despite all this, none of the results are truly actionable in the context of OE, which I'm stating more to address anybody else that comes along since you seem to have a pretty good grip of the situation yourself. Any manager who starts running these queries and axing people based on the results will find themselves on the chopping block in short order.
- doingTheLegWork 3y agoI appreciate the reply. When you say you do this for a living, what do you mean? Is your role to sniff this sort of thing out, a whole company, or part of your job on a team? I agree, none of this is evidence, just intel here. Not sure if we have Defender ATP. We have MDE, which I am starting to dig into now. I don't have direct access, so just looking through pulls after I make a request. For the devs, a simple glance at their gitlab contributions tells you a lot. For remote folks the VPN is another like the logins. The truly lazy won't even bother to be on the VPN, but doesn't mean they are not working. Apparently one of our main sys admins is never on the VPN. It would be nice if some of the enterprise licensed tools gave some metrics like Outlook, intelliJ/VSCode, and Gitlab, all overlaid on a simple bar chart of activity. It would be pretty easy to see gaps and to piece together a work day. I realize that doesn't account for whiteboard time etc, but that stuff is explainable. 3-4 hours per day of activity + very low contributions is not explainable. I don't think we have gone up against a real professional yet. If they are here, they are really good. It's a pretty small team and low output sticks out like a sore thumb.
- jstarfish 3y ago> Is your role to sniff this sort of thing out, a whole company, or part of your job on a team? Internal [cyber]investigations. We branched off from cybersecurity, but there's a sister team that handles traditional cases (anything not involving digital forensics). > We have MDE, which I am starting to dig into now. If you're talking about Defender for Endpoints, that might be the same thing (I can't keep up with Microsoft's product shuffling). There should be a dashboard you/the admin can access at security.microsoft.com, with a cylinder database icon (Advanced Hunting) in the top left corner that lets you run KQL queries like the ones I shared. > For the devs, a simple glance at their gitlab contributions tells you a lot. For remote folks the VPN is another like the logins. The truly lazy won't even bother to be on the VPN, but doesn't mean they are not working. Apparently one of our main sys admins is never on the VPN. Again, kudos for your restraint. Divining truth from ambiguity is not easy. Commit counts can be an inverse metric. Bad devs overinflate their commits ("typo correction lol"), and those diligently trying to iron out bugs and working on genuinely-hard problems will have less code to commit. My own VPN usage is spotty, and I'm remote. I just don't always need to be on it-- I spend a ton of time looking at spreadsheets and logs locally. Email, Slack and OneDrive work when I'm not on the corporate network, so sometimes I don't even notice I'm not connected. Your sysadmin...be careful there. I'm literally seeing the same thing wrt low/no logins of one of ours, but any number of witnesses could confirm he's actively working (attends meetings, available when needed, tasks are completed, etc.). It's just not clear to me how he's doing the job. The nature of that role also makes them a dangerous person to piss off. No one data point means more than any other. It's all a game of how many red flags, in aggregate, does the individual raise? > I don't think we have gone up against a real professional yet. If they are here, they are really good. The single biggest facepalm of my career occurred when I live-demoed this concept to the rest of the team and outed one of our own. I assumed it was a glitch, but others were harboring suspicions they couldn't justify raising until I presented numbers suggesting that the individual wasn't even logging into their computer. Still wasn't enough to take direct action on...but they did not survive the next round of layoffs.