tag:blogger.com,1999:blog-9518042.post6903728198568881700..comments2024-03-19T07:46:20.437-05:00Comments on Windows Incident Response: Threat Actors Changing TacticsUnknownnoreply@blogger.comBlogger3125tag:blogger.com,1999:blog-9518042.post-54230236715742209862023-03-19T08:37:44.585-05:002023-03-19T08:37:44.585-05:00Andreas,
> ... is it because of decoys, is it ...Andreas,<br /><br />> ... is it because of decoys, is it because your acting outside of the focus of the security teams. <br /><br />It's not any *one* thing...it's a determination made based on the totality of data. Sometimes, it's much more "sophisticated" to use an LOLBin rather than bring your own tool, one that is likely to leave an impact on the system. There's also situational awareness...I've seen some threat actors remove (or attempt to) AV when their commands are blocked (had no effect whatsoever), and I've seen threat actors first look to see what's installed, and then check the infrastructure to see if that EDR agent is installed on other systems. In one instance, the threat actor immediately moved to a system where Falcon was *not* installed.<br /><br />Something else to consider is clean up...does the threat actor not bother at all, do they "clean up all the things", or do they log in and launch a script that clears only the last 4 min of the Security Event Log? Or, do they simply modify the logging via auditpol?<br /><br />So, sophistication is based on a number of factors. I've been on engagements where a fellow analyst stated that the threat actor was "not sophisticated at all" because the commands they ran were noisy and left a lot of tracks on the system. I had to remind the analyst that we were there, responding, 8 months *after* the threat actor had departed.<br /><br />> And you know that only AFTER the hack which makes it always surprising for all.<br /><br />Yes, and no. <br /><br />We know it AFTER the hack, *for that incident*, but we know it well ahead of time from all of the other incidents we've responded to.<br /><br />Case in point...7 Feb 2022, MS announced that they were going to change the default behavior of systems, and block macros in Office docs downloaded from the Internet. Even today, this attack *still* works, including using old-style, OLE-based .doc files...because some orgs have not made the necessary changes. <br /><br />So, we've known about this (and other measures) as a protection mechanism for a long time, but (like patching), we just don't do it.<br /><br />>> most analysts won't "get" that it was disabled<br /><br />> It's not available in EDR logs...<br /><br />It very likely would be, as it can be easily set up via reg.exe, and that telemetry would exist for most EDR tools. Those that monitor Registry mods might not include it because the telemetry may be filtered based on sheer volume.<br /><br />> ...knowing the tools which cover such a technique is also a time consuming task...<br /><br />Not really. It is time-consuming because we choose to not pursue it or understand it.<br /><br />But I do get what you're saying...that an arbitrary organization sitting out there, with just it's current staff, isn't necessarily going to be able to keep up with everything...yeah, I get that. <br /><br />> If such a technique gets more common, it will eventually find its way into the regular analysis procedures of all.<br /><br />Or, we can just change the overall process, and start including it in tools now. Checking for null-bytes at the beginning of key and value names in the Registry? Done. Checking for RLO characters in Registry key and value names? Done. Checking the sizes of Registry values, based on type, so you can find "large" outliers? Done.<br /><br />I wrote Events Ripper (https://github.com/keydet89/Events-Ripper), in part, to preserve those things that I only saw once...such as the "Windows Defender/2051" event...so that they would be searched for on *every* engagement, and I didn't have to remember to look for it...and so that other analysts using the tool didn't have to have the same experience, and do the same research that I did.H. Carveyhttps://www.blogger.com/profile/08966595734678290320noreply@blogger.comtag:blogger.com,1999:blog-9518042.post-45215111530370601862023-03-18T11:47:01.383-05:002023-03-18T11:47:01.383-05:00a truly sophisticated attack
True true, and soph...<i> a truly sophisticated attack </i><br /><br />True true, and sophisticated must not be sophisticated in technical versatility, but in just not being seen by the defenders, is it because of decoys, is it because your acting outside of the focus of the security teams. It doesn't matter if it was highly technical or not, if attackers achieve their goal and stay hidden, it was sophisticated enough. And if it only needs basic tooling. BEC after phishing, not very sophisticated, but highly effective.<br /><br />---<br /><br /><i>A lot of basic security measures are "hard" and "expensive" because we're not doing them.</i><br /><br />And you know that only AFTER the hack which makes it always surprising for all. Unfortunately, the price one pays for missing the prevention mechanisms is only visible after the fact. It's the same for body, mental, earth health. Until then, we can dream, hope, make ones life's easier to not doing the home work.<br /><br />After all, every hack of one of the participants in the systems will make the overall security of the others a little bit better. Anti-fragility at best (some thoughts about that <a href="https://github.com/Karneades/CyberTriad" rel="nofollow">here</a>). One company is fragile, the overall system is more robust and hopefully learns.<br /><br />So now, what do we do about that? I think that the issue with these articles on some platforms calling everything "new" and "sophisticated" and "not seen ever" just to be journalism in mainstream media. Less people in my community talk about attacks like that. And the others, (1) train security analysts to keep the overall pictures in mind, know the tools and the tricks used by more advanced groups and (2) writing good article as you did to alert and making people aware of that.<br /><br />---<br /><br /><i>most analysts won't "get" that it was disabled</i><br /><br />How should analysts in typical SOC/DFIR teams know that? And the other 20 sneaky things?<br /><br />It's not available in EDR logs, it's not available in this or that fancy UI. And knowing the tools which cover such a technique is also a time consuming task. Who has the time to study relevant tools… How many teams have forensic experts in their teams which checking for null bytes when some tools fail to parse the registry files? Checking COM hijacking? Checking for malicious eBPF filters on Linux servers? Knowing that there are malicious eBPF software at all. There are so many thing to keep in mind during analysis, that people obviously focus on the most common things. Like the well-known video with the basketball players and the monkey walking by. And when do you know, that you can stop because you did enough for that specific case. It's not surprising at all that we miss such sneaky changes. If such a technique gets more common, it will eventually find its way into the regular analysis procedures of all. <br /><br />I could imagine that more algorithm based support in analysis (not parsing, but analysis), as it is getting more common in medicine too, would help reduce such blind spots for more hidden corners.<br /><br />---<br /><br />As your write-ups helps a lot and I shared many post with my peers, it helps to to focus on the education and the analysts way of thinking, as Chris Sanders did in his <a href="https://chrissanders.org/2021/12/dissertation/" rel="nofollow">dissertation</a>.Andreasnoreply@blogger.comtag:blogger.com,1999:blog-9518042.post-43126397665506909882023-03-18T06:46:13.828-05:002023-03-18T06:46:13.828-05:00"And what is called „sophisticated“ says mayb..."And what is called „sophisticated“ says maybe more about the speaker than the actual attack."<br /><br />Exactly. <br /><br />For me, a truly sophisticated attack would be one that was profound in how remarkably simple and complete it was. For example, create a Run key value, but disable it...most analysts won't "get" that it was disabled, and since the industry, for the most part, does not purse validation, this is a pretty simple red herring. Grab something off of VT, something that is attributed to another TA group, drop it on disk, create and then "disable" persistence.<br /><br />Then go about your real task. Enable RDP, set StickyKeys, hide the user account from the Welcome Screen. <br /><br />Want to have some real fun? Don't do these all on the same system.<br /><br />Most often, "sophisticated" is really the 800 lb gorilla. No one wants the world to know that they got beat up by a 12 yr old girl in a wheelchair, so they say, "...it was an 800 lb gorilla...". After all, they said it, so it *must* be true. <br /><br />When you look at the details of most incidents, what do we see? User double-clicks an ISO file attachment, something they've NEVER seen before, and then launches the malware inside the disk image file. Or, RDP is left open with an easily-guessed password...or maybe not so easily guessed, but no one was watching the logs as that system was subject to brute force attacks over weeks and months.<br /><br />A lot of basic security measures are "hard" and "expensive" because we're not doing them.H. Carveyhttps://www.blogger.com/profile/08966595734678290320noreply@blogger.com