Coyote in the Wild: First-Ever Malware That Abuses UI Automation
Source: https://www.akamai.com/blog/security-research/active-exploitation-coyote-malware-first-ui-automation-abuse-in-the-wild
How We Accidentally Discovered a Remote Code Execution Vulnerability in ETQ Reliance
Source: https://slcyber.io/assetnote-security-research-center/how-we-accidentally-discovered-a-remote-code-execution-vulnerability-in-etq-reliance/
The Internet Red Button: a 2016 Bug Still Lets Anyone Kill Solar Farms in 3 Clicks
Source: https://reporter.deepspecter.com/the-internet-red-button-a-2016-bug-still-lets-anyone-kill-solar-farms-in-3-clicks-042eeca7df33
A Novel Technique for SQL Injection in PDO’s Prepared Statements
Source: https://slcyber.io/assetnote-security-research-center/a-novel-technique-for-sql-injection-in-pdos-prepared-statements/
Inside the ChatGPT iOS app, I’m using the built-in code interpreter. Every time I ask it to scan for open ports, it shows port 8080 bound to 0.0.0.0, not localhost, like it used to. Happens across sessions, even after restarting the phone and turning off the local network feature in app settings.
Same PID (3), same process (python3). Also seeing two private IPs (10.x.x.x) and localhost loopbacks, about 18 of them. As well as access to internal libraries, A LOT of them.
Looks like something is preloaded inside the interpreter container. Anyone know what this is?
As I’m writing this, apparently the localhost connection to 8080 is weirder than 0.0.0.0.
I’m clearly clueless, but I noticed a weird change and decided to share.
Hi all,
I am a cybersecurity analyst with 1 year and 6 month experience. Im writing this for fun and to teach some people who maybe interested and are at a beginner level on detecting suspicious sign in activity.
In my example Im going to be using Entra ID, as this is the most common IAM solution and the one Im most familiar monitoring.
First step is analyzing the alert you received in the queue.
"Impossible travel time" or "Anomalous sign in activity" "sign in from bad IP" - These are the type of suspicious authentication logs that you will see in the SOC.
Gather all the information:
time generated (time of the sign in)
app that was logged into (ex officehome, msgraph)
username/email
IP address
device info (will normally be blank if its tuned properly, if its coming from managed trusted AD device it is a big indicator its benign so need to tune it to avoid FP for VPN usuage)
locationdetails (will be crucial to see which location logged from, will determine later if its physical location or location from VPN server)
user agent (crucial to detect what type of device it's coming from, potential spoofing as well)
Then you can run a query like this (will differ greatly based off your SIEM querying lanaguage, Im using Kusto MS Sentinel)
Signinlogs
| Summarize count by timegenerated, appname ,userprincipalname, IPaddress, tostring(locationdetails), tostring(deviceinfo), useragent
| where resulttype == 0 (filtering to see successful sign in attempts only)
\^ use a query like this to gather all crucial details, we can then use the time range to see 24 hours and then compare past previous sign ins from last 2-3 weeks to see a baseline, for location, IP address, device info, to see if they have accessed that app before.
Once you determine the sign in activity is indeed suspicious, its a combination of blank device details (non managed device), new IP address, new useragent or a suspicious useragent (potential spoofed), new app that's been used and potential impossible travel based off the last successful login). We need to analyze what type of IP address is being used, from either a VPN server or a ISP IP (will show approximate physical location of actual sign in).
NEVER just focus on the IP reputation, vast majority of the true positives I caught are all coming from clean IP reputations, threat actors are smart enough to know that if their IP address has been flagged and reported numerous times, their sign in activity will be blocked. Analyze the ISP info, a threat actor MAJORITY of the time will be using an IP address from a suspicious VPN server, you can do a ISP search for that VPN name and most of the time it will be something foreign.
Once you confirm the IP is coming from a suspicious entity such as a VPN server that is not authorized to be used in the company or its a VPN server with suspicious name, can confirm it's indeed malicious.
From there you can quickly check Auditlogs table to see any major changes to the users account. Most threat actors will remove and change the comprised users MFA, will remove the comprised user mobile device and probably add theirs.
From here, you can check the email logs and url click events on the suspicious link that was clicked for them to be comprised. Once you find that suspicious email you can plug that phishing URL into a interactive sandbox such as Browserling to confirm it. Some threat actors phishing sites are capable of detecting sandboxes and won't show their sign in page so be wary of that, but this isn't very common.
After detecting all these suspicious events, you can begin to lock the users account, resetting MFA settings and starting the IR process and doing some forensics on what the threat actor did.
Will have to look for:
\- Potential data exfiltration attempts. Can detect this from email logs or web traffic logs.
\- Potential lateral movement, the threat actor will likely send the same phishing email but this time from comprised users account to other internal users. Can detect this from email events as well.
\- File modifications - the threat actor could have modified a file, deleted a file, for this can check logs such as office activity (365 events)
Your Loyalty Card is a Liability: Lessons from the Co-op Attack
Source: https://substack.com/@alex133134/note/p-168474995?r=625rp3&utm_medium=ios&utm_source=notes-share-action
Copy-Paste Pitfalls: Revealing the AppLocker Bypass Risks in The Suggested Block-list Policy
Source: https://www.varonis.com/blog/applocker-bypass-risks
IPv6 security has recently become a pressing issue. In this article, I will discuss attacks on IPv6 and methods of protection.
This article discusses attacks on IPv6 using passive NDP sniffing, RA spoofing, RDNSS spoofing, and DHCPv6 snooping. It also discusses methods of protection against these attacks.
For unknown, and regrettable, reasons, these 2 awesome utilities now embeds adwares !
It is recent:
- For CrystalDiskMark, this starts from version 9.0.0.
- For CrystalDiskInfo, this starts from version 9.7.0
You can see the "*ads.exe" files:
- hxxps://sourceforge.net/projects/crystaldiskmark/files/9.0.1/
- hxxps://sourceforge.net/projects/crystaldiskmark/files/9.0.0/
- hxxps://sourceforge.net/projects/crystaldiskinfo/files/9.7.0/
More explanations here: hxxps://forums.tomshardware.com/threads/is-crystaldiskinfo-still-safe.3882065/
