When you’re in the middle of an incident response, memory analysis is one of the most powerful ways to uncover what really happened on a compromised machine . RAM is volatile—it disappears once the system is powered down—so examining it quickly and thoroughly can give you insights into malware, lateral movement, persistence, and more. This will walk you through examining RAM and dumping processes using Volatility (standalone) on Windows . It’s not exhaustive, but it will get you started with the essential plugins and workflow. ------------------------------------------------------------------------------------------------------------- Step 1: Identify the Operating System Before diving into analysis, determine the operating system of the memory image. windows.info This will give you basic information about the image and help guide which plugins will work properly. Step 2: Examine Processes List running processes windows.pslist.PsList > pslist.txt Do a process scan  (check running PIDs and PPIDs): windows.psscan.PsScan > processes.txt Look for hidden/rogue processes windows.psxview.PsXView > psxlist.txt List and analyze DLL handles of suspicious processes windows.dlllist.DllList > dlllist.txt Step 3: Network Connections Check for active or historical network connections: windows.netscan.NetScan > netscan.txt Step 5: Registry and Execution Artifacts UserAssist Keys windows.registry.userassist.UserAssist > userassist.txt Amcache windows.amcache.Amcache > amcache.txt Shimcache (AppCompatCache) windows.shimcachemem.ShimcacheMem > shimcache.txt These registry-based artifacts often reveal executed programs, including those that may not show up in process lists. Step 6: Dump Processes and DLLs Create a directory inside your Volatility standalone folder for process dumps. Dump all processes: --dump -Processes Or dump DLLs from suspicious processes: --dump -DLL Once dumped, scan them with multiple antivirus engines. A quick way: right-click the directory and run scans. Step 7: Look for Injected Code Use malfind to find embedded/injected code within processes: windows.malfind.Malfind > malfind.txt Dump these results to the same directory and scan with AV. Step 8: Search for IP Addresses Use strings or bstrings to extract potential network indicators from memory: strings memorydump.raw | findstr "IP" > IP.txt 📌 Guide: https://www.cyberengage.org/post/memory-forensics-using-strings-and-bstrings-a-comprehensive-guide Step 9: Explore More Plugins Volatility has many plugins beyond the basics. You can always check available options with: volatility -h Each case is different, so don’t limit yourself to just the above commands. Bonus: Alternative Tool – MemProcFS One of my favorite tools alongside Volatility is MemProcFS . Unlike Volatility, you don’t need to dump anything manually—everything is already “mounted” and accessible like a file system. 📌 Guide: https://www.cyberengage.org/post/memory-forensics-using-strings-and-bstrings-a-comprehensive-guide ------------------------------------------------------------------------------------------------------------- "Note: The commands shown above are not full commands but rather the plugins you can use. You’ll need to run them with Volatility 3 in the proper format The plugin names I’ve listed are to guide you through which modules are useful during analysis." ------------------------------------------------------------------------------------------------------------- Final Thoughts These steps and plugins are enough to get you started with memory analysis during an investigation. As you get deeper into cases, you’ll find yourself using other plugins or combining results with disk/timeline analysis. The main takeaway: Start broad with processes and network activity Narrow down to execution artifacts and persistence Always dump and scan suspicious processes Correlate memory findings with disk and event log evidence Memory doesn’t lie—if something malicious ran, you’ll find traces of it here. Happy hunting! -----------------------------------------------------------Dean---------------------------------------------

When I look back at all the articles, guides, and tool walkthroughs I’ve written, one question keeps coming up: “Where do we actually start?” It’s true—I’ve shown you dozens of tools, ways to parse artifacts, and countless steps for analysis. But an investigator or IR professional still needs a structured process . That’s why I decided to create this methodology. Think of it as a roadmap. Every investigation is different —you may skip some steps or add a few more depending on the case—but this gives you a clear starting point and flow to follow. Along the way, I’ll point to my detailed articles so you can dive deeper into each stage. ------------------------------------------------------------------------------------------------------------- 1. Mount Disk Image and Scan with Multiple AV Products This is the “low hanging fruit.” Always start simple. Mount your image with Arsenal Image Mounter (my go-to). Or collect the image in VHDX  format using KAPE  (which I always do). FTK Imager is another solid option. 📌 Guides: KAPE Series: https://www.cyberengage.org/courses-1/kape-unleashed%3A-harnessing-power-in-incident-response FTK Imager Quick Guide (PDF available under Resume → Quick Guides): https://www.cyberengage.org ------------------------------------------------------------------------------------------------------------- 2. Generate a Super Timeline You need context around suspicious events. A super timeline  shows you what happened before, during, and after. Use log2timeline/Plaso  (my personal choice). Or Magnet AXIOM  (great commercial option). 📌 Guides: Log2timeline article: https://www.cyberengage.org/courses-1/decoding-timeline-analysis-in-digital-forensics ------------------------------------------------------------------------------------------------------------- 3. Memory Analysis Memory tells the real-time story of execution. Focus on: Running processes and DLLs → dump and scan with AV Network connections Rogue or hidden processes Command history Malfind for injected code 📌 Guides: Memory Forensics Series: https://www.cyberengage.org/courses-1/mastering-memory-forensics%3A-in-depth-analysis-with-volatility-and-advanced-tools Recommended reads: Step-by-Step Guide to Uncovering Threats with Volatility MemProcFS/MemProcFS Analyzer: Comprehensive Analysis Guide ------------------------------------------------------------------------------------------------------------- 4. Process the Event Logs Events give timeline + context. Look for: Remote logins (Security, TerminalServices-LocalSessionManager%Operational) Service installs (System Event ID 7045) Type 3 logons around ransomware execution or PsExec installs Group policy changes AV being disabled/uninstalled Lateral movement Malicious PowerShell activity User account creation Event log clearing 📌 Guides: Lateral movement automation: https://www.cyberengage.org/post/lateral-movement-analysis-using-chainsaw-hayabusa-and-logparser-for-cybersecurity-investigations Hayabusa log analysis tool: https://www.cyberengage.org/post/hayabusa-a-powerful-log-analysis-tool-for-forensics-and-threat-hunting ------------------------------------------------------------------------------------------------------------- 5. File System and MFT Check: Suspicious file creations (batch scripts, malware samples, attacker directories) When encryption started (for ransomware) Suspicious compressed files → possible exfiltration 📌 Guides: MFT parsing with MFTECmd: https://www.cyberengage.org/post/mftecmd-mftexplorer-a-forensic-analyst-s-guide NTFS Journaling series: https://www.cyberengage.org/courses-1/ntfs-journaling ------------------------------------------------------------------------------------------------------------- 6. Malicious File Executions Key artifacts: Amcache ShimCache Prefetch UserAssist (NTUSER.DAT) 📌 Guides: Windows Forensic Artifacts: https://www.cyberengage.org/courses-1/windows-forensic-artifacts ------------------------------------------------------------------------------------------------------------- 7. Persistence Mechanisms Always check: SOFTWARE\Microsoft\Windows\CurrentVersion\Run SOFTWARE\Microsoft\Windows\CurrentVersion\Runonce NTUSER.DAT Run keys C:\Windows\System32\Tasks WMI Activity Operational.evtx 📌 Guides: Registry Forensic Series : https://www.cyberengage.org/courses-1/mastering-windows-registry-forensics%3A ------------------------------------------------------------------------------------------------------------- 8. USN Journal One of my favorite artifacts—great for file creations & deletions. 📌 Guide: USN Journal parsing with MFTECmd: https://www.cyberengage.org/post/ntfs-journaling-in-digital-forensics-logfile-usnjrnl-parsing-of-j-logfile-using-mftecmd-ex ------------------------------------------------------------------------------------------------------------- 9. Link Files See what files were accessed by a compromised account. 📌 Guide: https://www.cyberengage.org/courses-1/windows-forensic-artifacts ------------------------------------------------------------------------------------------------------------- 10. Shellbags Shows which folders were accessed. 📌 Guide: https://www.cyberengage.org/courses-1/windows-forensic-artifacts ------------------------------------------------------------------------------------------------------------- 11. Log Analysis Go beyond Windows: Firewall/VPN logs IIS logs IDS/IPS logs DNS logs SIEM-correlated logs 📌 Guide: Network Forensics: https://www.cyberengage.org/courses-1/network-forensic ------------------------------------------------------------------------------------------------------------- 12. Lateral Movement and Exfiltration Check: NTUSER.DAT → Terminal Server Client WinSCP.ini (shows remote connections & staging folders) OpenSSH logs Prefetch for sshd.exe SRUM DB for large transfers 📌 Guide: SRUM DB analysis: https://www.cyberengage.org/courses-1/srum%3A-unveiling-insights-for-digital-investigations ------------------------------------------------------------------------------------------------------------- 13. On-System Email Analysis Look for phishing origins: Original email Suspicious attachments Malicious documents 📌 Guide: Identifying malicious software: https://www.cyberengage.org/post/identifying-malicious-software-a-guide-for-incident-responders ------------------------------------------------------------------------------------------------------------- 14. Internet History Critical for phishing & exfil evidence. 📌 Guide: Browser forensics series (open-source tools): https://www.cyberengage.org/courses-1/introducing%3A-browser-forensics-%E2%80%93-your-ultimate-guide-to-manual-analysis ------------------------------------------------------------------------------------------------------------- 15. Data Carving Recover deleted or hidden items. 📌 Guide: Data carving series: https://www.cyberengage.org/courses-1/data-carving%3A-advanced-techniques-in-digital-forensics ------------------------------------------------------------------------------------------------------------- 16. Index Searching Search for IOCs in slack space & unallocated clusters. 📌 Guide: Windows forensic artifacts (indexing section): https://www.cyberengage.org/courses-1/windows-forensic-artifacts ------------------------------------------------------------------------------------------------------------- Modern Tools Worth Adding (2025) Velociraptor  – IR at scale, timeline generation, artifact parsing. KAPE  – rapid artifact collection. Eric Zimmerman’s Tools (EZ Tools)  – Amcache, Registry, Prefetch, etc. Timesketch  (Tmeline Explorer) – timeline review. Volatility3  – modern memory analysis framework. ------------------------------------------------------------------------------------------------------------- Final Thoughts This methodology isn’t about rigid rules. It’s about giving you a process to start with . Each case is different—sometimes you’ll skip steps, sometimes you’ll go deeper in certain areas. The key takeaway: Start broad (AV scans, timelines) Narrow down (memory, logs, persistence, artifacts) Always document and correlate across multiple data sources Use this roadmap, explore the linked guides, and adapt it to your investigations. Stay sharp, and happy hunting!

You know that old principle we all learned in programming — divide and rule ? Break the big problem into smaller pieces, solve those, and the whole thing becomes manageable. Well, guess what? That same idea is a lifesaver in incident response . A massive breach can feel overwhelming, but if you chop it down into standard, repeatable tasks , suddenly it’s not this monster anymore. It’s just a list of jobs to get done. Why Standard Tasks Matter Here’s the trick: don’t let the investigation depend on who  is working the case. If Investigator A does a host triage one way and Investigator B does it completely differently, you’ll end up with confusion and wasted time. But if everyone runs tasks the same way — and documents them properly — then anyone can pick up where the last person left off. That means: You can swap people in and out without breaking the flow. You can bring in someone fresh for a few hours and know exactly what they’ll deliver. You don’t lose speed when people rotate shifts. And here’s something I love: sometimes when you rotate people, that fresh pair of eyes notices something new that others missed. That’s the magic of collaboration. Resources: More Than Just People Now let’s talk about resources . Most folks think resources = analysts. But in IR, it’s bigger than that. Sure, you need responders, malware reversers, and intel analysts . But in big cases? You might also need enterprise architects (to help with recovery) or even negotiators (for ransomware). Don’t forget storage, bandwidth, and processing power. Tools are easy to buy but not easy to integrate. You can’t just toss in a new platform mid-incident and expect magic. Good processes and content take time to develop and test. Here’s the kicker: resources don’t scale easily in IR . That’s why the IR lead’s job isn’t just running the case technically — it’s also managing these resources like a chess game. Standardization Keeps the Chaos Out This is where standardization saves your life. Don’t just throw bodies at the problem — that creates noise and costs money. IR companies overstaff cases to cover. That only makes things worse. Instead, plan tasks and shifts carefully. Here’s a simple example: Three analysts on 8-hour shifts. A host triage takes ~5 hours(for full image) ~2 hours (kape image) → each analyst can do two a day. Persistence or evidence stacking takes ~2.5 hours. Onboarding a new analyst? Budget ~2.5 hours. If you manage the case close to this level of planning, the whole engagement runs smoother, faster, and cheaper. Deviations happen, but the goal is control, not chaos . The Power of Task-Driven Questions Here’s something : don’t deep-dive without a clear question. If you throw an analyst at a hard drive with no direction, they’ll dig for days and still not know when to stop. That burns time, money, and morale. Instead, assign tasks based on questions . For example: ❌ Inefficient:  “Analyze this entire hard drive.” ✅ Efficient:  “Find evidence of what data was exfiltrated from this host.” The moment the question is answered, the task is complete. Of course, analysts should still look a little left and right for context, but they shouldn’t drift aimlessly. This is how you keep investigations sharp, measurable, and efficient. ------------------------------------------------------------------------------------------------------------- Wrapping It Up Do that, and even the biggest, nastiest breach starts to look manageable. You’re not just firefighting anymore — you’re running a structured, controlled investigation. Because at the end of the day, IR isn’t about looking busy. It’s about restoring order in the middle of chaos .

When people hear incident response , they often picture someone hammering away at a terminal, pulling artifacts, and cracking malware. And yes, the technical side is critical. But in reality, IR is just as much about people, communication, and coordination as it is about tools and commands. ------------------------------------------------------------------------------------------------------------ Technical Mastery Still Matters Even though IR isn’t only about technology, make no mistake: you need people who know their craft . As an lead, when you assign a task, you expect results—not excuses. That means analysts must not only know how to operate their tools but also understand what the artifacts mean. Misinterpretation can be as dangerous as missing data entirely. Why do some of the best responders come from penetration testing backgrounds ? Simple: they understand the attacker’s playbook from the inside. Knowing how an adversary thinks makes it easier to spot their tracks. But the bar keeps rising. Modern enterprise networks are sprawling, with features like Active Directory forests, Azure AD, and cloud integrations. To hunt attackers effectively, you need more than endpoint knowledge —you need to understand how enterprises are actually built and where attackers can exploit trust relationships. This knowledge isn’t just for detection. It’s also essential for remediation . When you recommend rebuilding or rearchitecting systems, your suggestions have to be realistic in the context of a large enterprise. “Tools help you spot the smoke. But only experience tells you whether it’s a campfire or a forest fire.” ------------------------------------------------------------------------------------------------------------ Documentation: The Unsung Hero If visibility is the lens of IR, documentation is the map . Without it, you’re wandering in circles. Here’s why it’s indispensable: Tracking progress  – With multiple analysts working a case, you need to know what’s already been done, what failed, and what still needs attention. Stakeholder communication  – Clear documentation lets you brief management, legal, and external partners confidently at any point in the investigation. Intelligence integration  – While you document, threat intel teams can map artifacts against known adversaries, often giving you new leads mid-investigation. Future learning  – Every incident becomes a training case for the next. Documentation preserves lessons learned. Liability protection  – A clear record of what was done, when, and why is invaluable if the response ever comes under legal or regulatory scrutiny. ------------------------------------------------------------------------------------------------------------ Soft Skills: The Glue Holding It Together For the breached organization, a cyberattack is usually an exceptional crisis . For the IR team Bridging that emotional and professional gap requires soft skills —especially from the incident lead. The lead : Translate complex technical issues into language the board can act on. Support corporate communications and legal teams. Keep IT and SOC teams aligned and working toward the same goal. Reassure customers and partners that the situation is under control. Keep morale up—sometimes literally by ordering pizza and making coffee. In short: the IR lead is not just a commander, but a translator, negotiator, and motivator. ------------------------------------------------------------------------------------------------------------ The Anatomy of an IR Team A strong IR team isn’t just a handful of analysts— it’s a collection of specialized roles working in harmony: IR Lead  – Orchestrates the entire response, maintains the “big picture,” manages the artifacts and spreadsheets, and acts as the primary point of contact for external stakeholders. Analysts  – Carry out host triage, log sweeps, threat hunting, and containment tasks. They are the boots on the ground. Malware Analysts  – Dissect malicious code to uncover capabilities, extract C2 addresses, and provide in-memory IOCs such as YARA rules. Their work often determines how wide and deep the compromise goes. Threat Intelligence Analysts  – Correlate evidence with known threat actor behavior, enrich the case with context, and distribute curated IOCs to the right channels. Each role is critical, but the magic happens in how they collaborate . Clear tasking, shared documentation, and open communication are what transform a group of individuals into a coordinated response force. ------------------------------------------------------------------------------------------------------------ Final Thoughts IR may be a technical field, but technical skills are only part of the story . Documentation keeps everyone aligned, soft skills keep stakeholders calm, and specialized roles ensure no stone is left unturned. Because at the end of the day, incident response is about restoring control in the middle of chaos—and that takes more than just tools.

Before I start!!!! 💡 Credit where it’s due: This insight comes straight from J , one of the sharpest call investigators and my dearest friend!!. He’s been running into this exact phishing method a lot  lately in real investigations — because when the bad guys get creative, he’s usually the one who catches them. J also happens to run one of the best MDR services  I’ve seen — staffed with top-tier people, handling a serious volume of clients without breaking a sweat. And no, this isn’t a sales pitch — just the truth. But if you are  looking for an MDR service that actually knows how to handle incident response and forensics like pros, let me know. I’ll make sure you get connected to J directly… assuming he’s not too busy catching the next cybercriminal. --------------------------------------------------------------------------------------------------------- Alright, let me tell you about something J is seeing every single day  with his clients.These guys are constantly  getting phished — and the attackers aren’t even using anything exotic.They’re just… smart. Here’s the play-by-play. Step 1 — The Hacker’s Head Start The attacker doesn’t even need to create  a fake Microsoft account. Nope. They just buy or steal a real  one . Could be from the dark web, could be from an old breach, could be some poor guy’s account that got keylogged — doesn’t matter. Why is this important? Because that account is already trusted . It has Microsoft’s blessing. Security tools look at it and go, “Yep, that’s fine.” Step 2 — The “Perfectly Safe” Email So now the attacker sends our victim an email that says: "Hey, a document’s been shared with you on SharePoint." That’s it. No misspellings. No sketchy links. Just a real sharepoint.com link. Microsoft loves it. Barracuda loves it. Proofpoint loves it. Why wouldn’t they? It’s literally a Microsoft domain. Step 3 — Playing by Microsoft’s Rules The victim clicks the link and lands on… the real  SharePoint site. Microsoft says, “Hey, please type in your email so we can send you a one-time code.” The victim does exactly that.They get the code. They put it in. Boom — document opens. Everything so far is 100% legit. Even the security guys monitoring the logs would shrug. Step 4 — The Trap Inside the Doc Now comes the actual  payload. Inside that innocent-looking document is a link — but not just any link. It’s to a real Adversary-in-the-Middle (AiTM)  phishing site.Think of it like a sneaky mirror: you see Microsoft’s login page, but it’s secretly passing everything you type straight to the attacker. And here’s the killer part — it doesn’t just grab your username and password.It also snatches your MFA session cookie . That means even if you’ve got multi-factor authentication, the attacker can log in as you  without ever touching your phone. Why Security Tools Don’t Stand a Chance The phishing link never appeared in the email. It was hiding inside a document on Microsoft’s own servers. That means: Microsoft Defender for Office 365?  Nope — only saw a SharePoint link. Barracuda / Proofpoint / Mimecast?  Nope — nothing malicious in the email. Sandboxing?  Nope — the document doesn’t “run” anything bad, it just sits there with a clickable trap. By the time the victim clicks the malicious link, they’re already deep inside a trusted Microsoft session. Why This Works So Well Let’s break it down: It rides on Microsoft’s good reputation  — users and tools both trust it. The flow feels familiar  — the victim does the real  SharePoint steps before anything bad happens. The bad link is invisible  until after the secure login. MFA is useless  — because session cookies don’t care about your code. How to Fight Back (If You’re Defending) If you think this is just a “train your users” thing — you’re already halfway lost. Yes, awareness training helps, but you also need: Conditional Access Rules  – Don’t let logins happen from weird countries or impossible travel times. Cloud App Security  – Scan files in SharePoint/OneDrive for links to dodgy domains. External Sharing Limits  – Only allow shares from trusted domains. Live Session Monitoring  – Look for suspicious cookie reuse. Report Button  – Encourage users to flag any  document share they weren’t expecting. Why Red Teams Love This From a red team perspective, this is chef’s kiss: The email looks perfect. The infrastructure is Microsoft’s — no sketchy domains to register. The social engineering is minimal. MFA is just… irrelevant. The Takeaway The scariest part? The attacker doesn’t break  Microsoft security — they use it against you . If you’re defending, remember this: the danger isn’t just in the link your filters see. It’s in what happens after the click . ---------------------------------------Dean/J----------------------------------------

When people think of Incident Response (IR), they usually imagine technical skills—reverse engineering malware, parsing logs, or hunting persistence mechanisms. And yes, those skills matter. But the truth is, a successful large-scale IR effort depends on much more than raw technical expertise . Over the years, responders have identified several principles that consistently make the difference between chaotic firefighting and a controlled, effective response. -------------------------------------------------------------------------------------------------------- The Five Pillars of Incident Response Preparedness  – Incidents are inevitable, but failure doesn’t have to be. Being prepared means more than just having tools. It means having documented procedures, rehearsed playbooks, and a team that has trained together before the crisis hits. Collaboration  – Rarely is IR a one-person show. Real-world response efforts require coordination across internal teams, external partners, law enforcement, and sometimes even regulators. Good communication channels and collaboration tools are just as important as your EDR. Speed  – Time is critical. The longer attackers stay inside your environment, the greater the damage. IR teams must respond quickly and decisively to contain and minimize the impact. Flexibility  – No plan survives first contact with the adversary. Attackers pivot, escalate, and innovate in real time. Your IR team needs to adapt —whether that’s changing tactics mid-investigation or bringing in new expertise on the fly. Continuous Improvement  – Every incident is a learning opportunity. Post-incident reviews help refine playbooks, close visibility gaps, and strengthen your team for the next challenge. ------------------------------------------------------------------------------------------------------------- Turning Principles into Practice Those high-level principles sound great, but how do they translate into day-to-day work? In practice, a strong IR team must develop certain core capabilities : Visibility  – You can’t fight what you can’t see. Efficiency  – Resources are always limited. Use them wisely. Technical skills  – Deep knowledge of systems, networks, and malware is non-negotiable. Documentation  – Keeps the team aligned and prevents wasted effort. Soft skills  – Negotiation, communication, and leadership are the glue that holds the team together. Of these, visibility  is arguably the most fundamental. ------------------------------------------------------------------------------------------------------------- Why Visibility is the Bedrock of IR Think of visibility as the lens through which you view an incident. Without it, you’re responding blind. There are two key dimensions: How much of the environment do you see? For example, if a subsidiary network is connected but invisible to your monitoring tools, that’s a visibility gap. How deeply can you see into each endpoint or system? Maybe your EDR doesn’t scan live memory with YARA rules, or maybe a rootkit is fooling your tools. Those are also visibility gaps. Here’s the catch: great vertical visibility is useless if you only cover 50% of the machines. Likewise, wide coverage with shallow visibility leaves critical blind spots.  You need both. ------------------------------------------------------------------------------------------------------------- Real-World Lessons In one large-scale case, responders investigated 10,000 endpoints. Out of that massive population, attackers only touched 50 machines. That’s less than 0.1%. Without strong visibility, you’d never find them. And attackers are clever: They may stage ransomware in unexpected directories. They may move laterally using RDP, leaving subtle profile timestamps behind. They may hide malware only detectable with memory-based YARA scans. They may leave behind artifacts in RDP bitmap caches, which can be recovered with the right tools. The point is simple: visibility determines whether you can even ask the right questions  during an investigation. ------------------------------------------------------------------------------------------------------------- Always-On vs. On-Demand Visibility There are generally two approaches: Always-on visibility  – Continuous data collection via logging (Sysmon, NetFlow, EDR telemetry). On-demand visibility  – Point-in-time forensic acquisitions triggered when needed. Most organizations blend the two. What matters is recognizing where your gaps are and making sure your tools—and team—are capable of filling them. ------------------------------------------------------------------------------------------------------------- A Mindset Shift Some organizations limit themselves by defining investigations based only on what their tools already provide. That’s the easy way, but it’s short-sighted. A stronger approach is to start with the questions you need answered —then push your tools (or build new ones) to deliver the data. That mindset drives the industry forward and closes detection gaps. “Don’t let your tools define your visibility. Let your visibility requirements define your tools.” ------------------------------------------------------------------------------------------------------------- Closing Thoughts Visibility is the first battlefield in IR. Without it, attackers roam freely in the shadows. With it, your team has the context, evidence, and confidence to make informed decisions. But visibility is only one piece of the puzzle.

I never thought I’d write this article. This isn’t a motivational speech or a “5 steps to success” kind of blog. This is my story  — honest, emotional, and something I hope breaks a few myths many people still believe about getting job abroad. Before I dive in, let’s start with a few common myths: ------------------------------------------------------------------------------------------------------------- Myths I Want to Break You can only get a job abroad after studying there. You need to spend 30–40 lakhs on a foreign degree to settle overseas. Cybersecurity professionals don’t get hired abroad from India. Only people with 9–10 years of experience get sponsored jobs. Let me tell you how wrong these assumptions are — and how my journey proves that. ------------------------------------------------------------------------------------------------------------ My Journey — From a Small Town in India to an International Offer Like many others, I dreamt of studying abroad, getting a good job, and building a life there. But reality was different. Financial conditions at home didn’t support that path , so I stayed in India, completed my studies, and started my career at Infosys. It was during my time at Infosys that I had a realization: "A regular job and degree won’t get me where I want to be." So I started self-studying after work — deep-diving into cybersecurity, reading, experimenting, and learning late into the night. I joined ConnectWise, and that’s when I decided to create my personal website .Not just to share knowledge — but to showcase my potential  to companies across the world. I had no money to move abroad or pay for foreign education, but I believed one thing: 💡 “If I can’t go to them, maybe my work can reach them.” ------------------------------------------------------------------------------------------------------------ The Rejections That Almost Broke Me Once I was confident, I started applying — 20 to 30 job applications every single day for continuously 3 years . Seek. Monster. LinkedIn. Company websites. You name it, I was on it. Each morning, I’d wake up to rejection emails . Some companies ghosted me after interviews. Others rejected me after final rounds due to visa issues. Some just hired someone else. At times I wanted to give up. I remember saying: "Why am I doing this? Maybe I’m not good enough." But I kept going. Kept learning. Kept writing articles. Kept pushing. ------------------------------------------------------------------------------------------------------------ How Things Turned Around Then I joined Ankura , where I met fantastic people like Peter Vu . He became a mentor, someone I truly admired. When he left, I started applying abroad again. This time, something changed: my website had gained visibility . People shared my posts on LinkedIn, Twitter, government websites or pdfs . My work was speaking for me. And finally — after 3 failed interview attempts, I received a job offer from abroad. Not just a job — but a company willing to sponsor me . (A guy with 4 year of experience) ------------------------------------------------------------------------------------------------------------ What I Want You To Know This isn’t just my win. This is a message to everyone out there: You don’t need 10 years of experience  to get hired abroad. You don’t need 40 lakhs  for a foreign degree. You can be hired in cybersecurity  directly from India. All you need is resilience, willingness to learn, and consistency . I faced countless rejections , but kept showing up.I kept learning. I kept building. And now, I’m moving. ------------------------------------------------------------------------------------------------------------- Final Words: To Anyone Dreaming Big If your parents can’t afford to send you abroad — it’s okay. If you’re facing rejection after rejection — it’s okay. If people tell you “this isn’t possible” — smile and keep going. Because it is  possible. You don’t need to follow the traditional route. You don’t need to lose yourself in self-doubt. You just need to start , and not stop . And one day, your Yes  will come — just like mine did. ---------------------------------------------------------------Dean-----------------------------------

DNS is often referred to as the phonebook of the internet — and traditionally, it’s been fairly easy to read. But as privacy and censorship concerns grew, so did efforts to encrypt DNS traffic , giving us technologies like DNS-over-TLS (DoT)  and DNS-over-HTTPS (DoH) . While they offer legitimate security benefits, these methods also pose serious challenges for incident responders and forensic analysts . =Traditional DNS vs. DoT and DoH Let’s start with what’s familiar: traditional DNS queries, typically using UDP over port 53 . These queries are sent in plaintext, making them easy to observe in tools like Wireshark. For example, a simple A record lookup for https://www.cyberengage.org/  might be just 32 bytes of DNS payload  — and it’s all visible to anyone monitoring the wire. Now compare that with: DNS-over-TLS (DoT) Protocol : DNS traffic over TLS (like HTTPS, but just for DNS). Port : Default is TCP/853 . Benefit : Encrypts DNS traffic, preventing outsiders from seeing which domains are being queried. Visibility : Possible to block or detect based on port/protocol — unless the attacker starts tunneling DoT through a different port. DNS-over-HTTPS (DoH) Protocol : DNS sent as part of a regular HTTPS request. Port : TCP/443  — indistinguishable from regular web traffic. Challenge : Blends perfectly with normal browsing traffic. Visibility : Basically zero unless you're doing TLS interception , which is controversial and legally risky. A Closer Look at DoH in Action DoH can send DNS data in two ways: POST method : The DNS payload is dropped into the body of the POST request. GET method : The DNS payload is Base64-encoded and appended as a URL parameter. In both methods, the transaction ID is set to zero , as per the DoH RFC. This allows DoH responses to be cached, which isn't possible with randomized IDs. While these may look like regular HTTPS traffic, they’re actually DNS queries in disguise — a huge blind spot  if you’re only monitoring port 53. The Problem with TLS Interception TLS interception (aka SSL decryption) is the most reliable way to see inside DoH traffic, but let’s be real — it’s tricky and controversial . Here's why: Technically : It works. Middleboxes decrypt the traffic, inspect it, then re-encrypt and forward it. Legally : Risky. This is considered intrusive in many regions and can violate privacy laws. Operationally : Complex. You need tight certificate management, and every endpoint must trust the interceptor. Because of this, many orgs simply don’t go down this road — even if they’d like to. Other Detection Options So how do we detect or control encrypted DNS if we’re not intercepting TLS? For DoT: Block or monitor TCP/853 . Use firewall rules  to prevent outbound connections on uncommon ports. Track DNS servers in use and look for rogue ones. For DoH: Traffic profiling : Since DoH is just HTTPS, you can analyze traffic behavior (e.g., regular POSTs to dns.google or cloudflare-dns.com). Control system and app settings : Disable DoH in browsers, OS, and apps where possible. But malware won’t respect your group policies. Enter Punycode and Internationalized Domain Names (IDNs) Now let’s throw another wrench into DNS analysis: Punycode , the format used for IDNs  (Internationalized Domain Names). Here’s the problem: DNS was built in an ASCII-only world . As the internet went global, p eople needed non-English characters in domain names . Enter Punycode — a way to encode Unicode characters using only ASCII. But here’s where it gets dangerous: visual spoofing . Example: Legit domain: wix.com Spoofed domain: wıx.com (note the Turkish “ı” character instead of “i”) To the human eye, they look identical. But behind the scenes, the punycode version might be: xn--wx-ema.com Forensic Tip: Any domain that starts with xn-- is a punycode domain. Use online tools or Python libraries to decode them and inspect their real intent. Not every punycode domain is malicious, but they deserve scrutiny , especially in phishing investigations. Final Thoughts: What You Should Be Doing Now Encrypted DNS and IDNs aren't going anywhere. They’re part of the modern internet — for better and worse. Here’s what defenders can do: Log everything  — especially DNS queries, NetFlow, and HTTPS metadata. Monitor DoH/DoT behavior  and block unauthorized resolvers. Identify punycode domains  and decode them during investigations. Use passive DNS  to track patterns over time, detect beaconing, and flag newly seen domains. Build user and host baselines  to catch anomalies in DNS behavior. Malware authors love DNS because most people don’t watch it closely. But once you start paying attention, DNS can tell you exactly what your adversaries are doing  — you just need the right lens to see it. --------------------------------------------------Dean-----------------------------------------------

In the ever-evolving cat-and-mouse game of cyber defense and offense, one technique has proven especially resilient: Domain Generation Algorithms (DGAs) . While not a brand-new tactic, DGAs are still actively used in modern malware campaigns to maintain command-and-control (C2) connections, avoid takedowns, and scale operations across thousands of infected machines. What is a DGA, and Why Do Malware Authors Use It? Think of a DGA as a recipe that allows malware to generate a list of domain names on the fly — usually hundreds or thousands per day. These domains are potential addresses the malware can use to check in with its command server. Here’s how it works: Malware on an infected host uses a DGA to generate a new list of domain names each day , often based on a seed value like the current date. The attacker just needs to register one of those domains , and the malware will be able to connect to it. If defenders block or take down that domain, it’s no big deal — tomorrow, the malware generates a new list. This technique makes it incredibly difficult to cut off communications  between infected machines and their controllers. Detecting DGA Domains: Easier Said Than Done Unfortunately, spotting a DGA in the wild is tough. These domain names are often random-looking gibberish , which helps — but it’s not a guarantee. There are legit services that use odd domain naming conventions too. Some detection strategies include: Heuristics : Analyzing the randomness of domain names. Newly observed or registered domains : Malware often uses fresh domains that have never been seen in your environment before. External threat intelligence : Feeds can help identify known DGA domains or similar patterns. But don’t expect perfection. DGA detection tends to walk a fine line between catching malware and flooding analysts with false positives . When Good Detection Goes Wrong: Chrome, ISPs, and DNS Weirdness Here’s a curveball. Some tools — like Google Chrome or OpenVPN’s Viscosity client — intentionally generate random-looking DNS queries  as a way to detect DNS interception . For instance: If Chrome doesn’t get an NXDOMAIN when querying a nonsense domain, it suspects your ISP is hijacking DNS responses (think ad pages or redirect portals). These fake queries look a lot like DGA activity . This is a nightmare for defenders relying on heuristic DGA detection — because now even legitimate software is acting like malware , from a DNS perspective. Pro tip: Look for patterns like .viscosity as a TLD or interface names in DNS queries. These can give away what system or client software was responsible for the "weird" behavior. Passive DNS: Your Secret Weapon This is where passive DNS logging  shines. By collecting and analyzing DNS traffic over time, you can: Catch DGA patterns  based on frequency, TTL, and randomness. Spot DNS rebinding attacks , where domains initially point to a public IP and later pivot to an internal one (useful for browser exploitation). Identify systems querying uncommon domains  or rogue DNS servers. Correlate DNS queries with other artifacts  like NetFlow, HTTP logs, or IDS alerts to build a more complete picture. Establish a baseline  of common domains, then investigate anything outside that norm. Bonus benefit : It also helps identify stealthy malware that "sleeps" by pointing C2 domains to 127.0.0.1 or hosting providers like AWS or Azure until the attacker is ready to activate it. Final Thoughts: It’s a Marathon, Not a Sprint DGAs, fast-flux, DNS rebinding — they’re all pieces of a much larger puzzle. They may look complex at first, but with the right data and detection strategy, you can start seeing patterns. It’s true that defenders have to be right 100% of the time , while attackers only need one successful connection. But by collecting DNS logs, correlating with threat intel, and understanding these sneaky techniques, we give ourselves a much better chance of winning that fight. ------------------------------------------------Dean-----------------------------------------------

Cybercriminals are always evolving, and so are their tactics. One particularly sneaky method that’s been gaining ground over the years is fast-flux DNS  — a trick that makes it extremely difficult to block malicious infrastructure or shut down campaigns. If you’ve ever wondered how malware manages to keep its command-and-control (C2) servers hidden in plain sight, fast-flux might just be the answer. What Is Fast-Flux DNS? At its core, fast-flux DNS  is a clever way for attackers to hide the real  location of their C2 servers. Instead of pointing a domain to a fixed IP, the DNS records (specifically the “A” records) rotate rapidly — sometimes every few minutes. Here’s how it works: The DNS record for a malicious domain doesn’t return one fixed IP. Instead, it returns a list of IP addresses , each belonging to a compromised machine  acting as a proxy. These machines forward the traffic to the actual C2 server, which remains hidden. The attackers also configure the TTL (time to live)  of the DNS records to be really low — usually less than 5 minutes — ensuring that the IP list keeps changing constantly. This means defenders can’t just block a static list of IPs or domains — because they’re outdated almost instantly. Why It's So Hard to Block Let’s say you identify a C2 domain being used in an attack. Blocking its IP address seems like a logical next step, right? Not so fast. Because the IPs tied to that domain change so rapidly — and are spread across hundreds or thousands of compromised devices — any blacklist is outdated by the time it’s implemented. This dynamic structure makes fast-flux highly resilient  and frustratingly evasive . Enter Double-Flux: Fast-Flux, But Worse If fast-flux is bad, double-flux  is worse. In a double-flux setup: The A records  (the IPs for the C2 domain) rotate, as before. But now, even the NS records  (which tell you which name servers to ask) are part of the rotation — and they too are compromised systems. So now, not only are the C2 proxies changing, but the DNS infrastructure itself is also constantly shifting. This adds another layer of obfuscation that protects the true source of control even further. So… Can We Defend Against This? Yes — but it’s a little more involved. Sinkhole known malicious domains: DNS admins can seize control of known bad domains by overriding the DNS resolution locally, stopping any resolution at the enterprise level. Use your DNS logs wisely: Logging DNS queries gives investigators powerful insights — who queried what, and when. It can help identify infected machines fast. Threat hunting with patterns: While fast-flux is tricky to prevent outright, it leaves patterns  in DNS traffic that can be used for detection and investigation. Detecting Fast-Flux: What to Look For Fast-flux DNS behavior has a few tell-tale signs . They aren’t foolproof — some legitimate services use similar methods for load balancing or geo-routing — but they can guide your threat hunting efforts. 1. Very low TTL values Fast-flux domains tend to have TTLs set to less than 5 minutes — the lower, the better (for them). That’s because they want the records to expire quickly, forcing frequent updates. Wireshark Display Filter: dns.resp.ttl < 300 2. Lots of IP addresses in responses Malicious domains in fast-flux networks often return many IPs in a single DNS response  — usually a dozen or more. This reflects the many compromised systems being used as proxies. Wireshark Display Filter: dns.count.answers > 12 (⚠️ Caution: This also happens in CDNs and load-balanced environments, so it’s not always malicious.) 3. Look for anomalies in your baseline The best method? Compare new DNS traffic to what’s normal in your environment. If a domain suddenly starts behaving in wildly abnormal ways — like resolving to 15 different IPs every few minutes — that’s a red flag. Final Thoughts Fast-flux DNS is a brilliant — and diabolical — tactic that makes life difficult for defenders. It’s built for resilience , evasion , and survivability , and when combined with double-flux and DGAs, it’s a nightmare cocktail. But with the right DNS logging setup, a solid baseline of what’s “normal,” and clever detection techniques, you can still track down infections and limit their impact. ---------------------------------------------Dean-------------------------------------------------

When we think about forensic investigations and threat hunting, DNS isn’t usually the first thing that pops into our minds. But if you dig a little deeper, you'll realize that DNS is often one of the most powerful sources of evidence  in any investigation. In fact, DNS logs are like a pulse check on your entire network. They silently record who's talking to who, when, and how — across nearly every protocol in use. Why DNS Matters So Much Attackers don’t walk through the front door shouting. They sneak around the back — and often, that backdoor is DNS. It’s used in everything from phishing and command-and-control (C2) infrastructure to data exfiltration. But here’s the thing: most networks don’t treat DNS seriously enough . They treat it as just another service, not a security tool. Imagine this: An attacker sets up a C2 domain and points it to 127.0.0.1 (localhost) most of the time to avoid suspicion. Then, when it’s time to activate implants, they change the DNS record to the actual IP. If you’re only logging queries and not responses, you miss that switch entirely. Good DNS Setup = Better Security If you're serious about DNS from a security perspective, there are a few best practices: ✅ Use internal DNS servers : Set up a small number of DNS servers inside  your network perimeter. 🔒 Lock down external DNS access : Clients should only  be allowed to query internal DNS servers — not open resolvers on the internet. 🌐 Use DHCP for DNS assignment : Keep it simple and consistent. 🚫 Block direct DNS access from clients to the internet : Use your firewall to enforce this. This configuration not only improves performance and reliability but also gives you a centralized choke point  for visibility. The Problem with Traditional DNS Logging Most DNS servers allow query logging , which is a good start — but here’s the catch: They don’t log the responses. That’s a big blind spot. It’s like watching only one side of a conversation. For investigators, this means missing out on crucial clues — like what IP a domain resolved to at a specific moment. And forget about using that data to spot malicious infrastructure that constantly changes — you'll be flying blind. Enter PassiveDNS Monitoring If you really want visibility, go passive . Passive DNS monitoring tools listen to DNS traffic and log both queries and  responses . One fantastic open-source option is Edward Fjellskål’s tool called PassiveDNS . It’s lightweight, fast, and versatile. You can: Run it live to monitor traffic as it happens (great for SIEM integration), Or process DNS traffic from pcap files during postmortem analysis. It can write logs directly or send them via syslog — which means it plays nicely with most log aggregators and SIEM platforms. 🧪 Practical Example: PassiveDNS in Action Let’s say you have a massive pcap file and you want to quickly zero in on DNS activity. PassiveDNS can do the job in no time: ( https://github.com/gamelinux/passivedns ) Installing PassiveDNS on Ubuntu, especially when running under Windows Subsystem for Linux (WSL), can be a bit challengin g. You might encounter several errors along the way due to the differences between a native Linux environment and WSL. However, you don’t have to worry you can reach out to me directly though email or using chat section, I will help immediately . Below is the official installation process for PassiveDNS on Ubuntu, as per the project documentation: $ sudo apt-get install git-core binutils-dev libldns1 libldns-dev libpcap-dev # libdate-simple-perl is also needed for pdns2db.pl $ git clone git:// github.com/gamelinux/passivedns.git $ cd passivedns/ $ autoreconf --install $ ./configure $ make O nce installation is done you have a pcap file and  you want to quickly zero in on DNS activity. sudo passivedns -r dns.pcapng -l ./passivedns.txt -L ./passivedns_nxdomain.txt This gives you two clean log files: One with all successful DNS resolutions One for those NXDOMAIN (nonexistent domain) queries — often a sign of malware trying to resolve C2 domains that don’t exist (yet) Output : And if you're live monitoring from a network tap: passivedns -i eth0 -D -y -Y This runs the tool as a background process, sending real-time logs (including failed lookups) straight to your syslog server. Final Thoughts If you’re skipping DNS logs in your investigations, you’re likely missing a massive part of the story. DNS isn’t just a boring infrastructure protocol — it’s a map of where your network traffic is going , and often a warning sign of where threats are coming from. So, whether you're hunting threats or digging through a breach, don’t underestimate DNS. It’s not just technical plumbing — it’s a forensic goldmine. --------------------------------------------Dean------------------------------------------------------

Let’s be real— dealing with hundreds (sometimes thousands) of user-reported phishing emails every day can be a nightmare for security teams . You’ve got analysts drowning in emails, managers worrying about response time, and users clicking “report” like it’s a game . That’s where ASA (Autonomous Security Analyst)  from Sublime Security swoops in like a superhero 🦸‍♂️—only smarter, faster, and it doesn’t need coffee breaks. So, What Exactly is ASA? Think of ASA as your virtual security analyst . It’s an AI-powered automation tool that investigates those user-reported emails that land in your abuse mailbox . It looks at everything, makes decisions, and gives you a neat little report so your real human analysts don’t burn out staring at spam all day. When someone reports a suspicious email, ASA jumps into action automatically —no need to press a button. It does the full analysis and tells you exactly what it thinks: is the message malicious, spam, graymail, totally fine (benign), or something it’s not sure about (unknown)? 🔍 What Does ASA Actually Do ? Here’s what makes ASA such a gem: Checks files and links for malware  🧨 Looks at logos and visual content  for phishing tricks 🕵️ Investigates the sender  to see if they’ve caused trouble before 📬 Points out misclassifications  or weird behaviors in the email 🤔 It does everything a human analyst would do—just way faster. 🛠️ How Do You Use ASA? If you're using Sublime Security in an Enterprise setup  and already have your abuse mailbox configured , it’s super easy. All you need to do is turn on the Automation  called “Send user reports to ASA” . That’s it. ASA is now your new team member. 🌍 Where Does ASA Live? Right now, ASA runs either in: Sublime’s cloud environment (SaaS) Or your own AWS cloud (self-hosted) Currently supported AWS regions include: 🇺🇸 Virginia | Oregon | Ohio🇪🇺 Dublin🇬🇧 London 🧑‍💼 ASA Has Two Personalities (a.k.a. Modes) 1. Passive Mode  – “The Analyst Buddy” ASA analyzes emails and gives you all the info, but it doesn’t take any action. You (or your team) still make the final call. Great if you want control, but still want a huge head start on the analysis. 2. Active Mode  – “The Autonomous Agent” ASA goes full robot mode 🤖—it analyzes, makes decisions, and takes actions  like: Quarantining bad stuff Moving spam to the junk folder Dismissing false positives Escalating uncertain stuff to a human analyst This is perfect when you need 24/7 automated help—especially when your team’s off the clock. 🗂️ ASA Verdicts: What Does It Call the Messages? ASA can label emails as: Malicious  – Dangerous! Spam  – Junk it. Graymail  – Meh, promotional or boring stuff. Benign  – Totally safe. Unknown  – Needs a human eye. For each verdict, you can set what ASA should do: quarantine, trash, move to spam, or just add a warning banner. 📋 ASA Reports: What Do You Get? ASA doesn’t just say “Spam” and walk away. It gives you a full breakdown , including: A one-liner summary  with verdict, user reports, and message actions An Executive Summary  with the juicy details A full attack chain  (if malicious) Deep-dive into the sender, content, attachments, links, and why ASA decided what it did Honestly, it’s like a mini threat intel report for every message. ------------------------------------------------------------------------------------- Before ending this article and after this one last left which is very interesting article!.. Let me show you last tab called admin Alright, so we’ve explored Sublime’s amazing features—from automations and verdicts to ASA doing the heavy lifting . But before we wrap this up, let’s quickly peek behind the curtain into the Admin tab —the place where the real control lives. It might not be the flashiest part of Sublime, but it’s where the magic of setup, permissions, and policies happens. Let’s break it down, no jargon—just straight talk. 😎 👥 Roles & Permissions Sublime comes with predefined roles  to help you manage who can do what: Admin  – Has full control. (79/79 permissions) Analyst  – Has what they need for investigations. (28 permissions) Engineer  – Somewhere in between. (47 permissions) 🧑‍🔧 Want more flexibility? If you're an Admin, you can create your own roles  and fine-tune permissions for users based on your team’s needs. 🗃️ Message Retention Settings You don’t want to keep every  email forever—but you do want to keep the important  ones long enough for investigations. Here’s what you can manage: Raw EML (Unflagged) : Pick how long to keep emails that weren’t flagged or reported. After this period, the message metadata stays, but body, links, screenshots, etc. are gone. Raw EML (Flagged/User-Reported) : These stick around longer. Same deal—pick the retention time. MDM Retention : MDMs (Message Data Models) are kept for up to 30 days or whatever your unflagged EML retention is (whichever is shorter). Think of this as your time machine settings—how far back in time can you go to re-analyze or investigate emails? 🔐 Authentication & Security Hook Sublime into your SSO  provider of choice: Okta ✅ Azure AD ✅ OneLogin ✅ Or any OpenID Connect or SAML  provider Also: You can control how people view message contents  (opt-in for extra control) And even set an IP Allow List  so that only approved IPs can access the Sublime dashboard or API. Very enterprise. Very secure. Abuse Mailbox – The Front Door for Phishing Reports If your users forward suspicious emails, this is where Sublime catches them . Set up your abuse mailbox (up to 5 addresses), and Sublime will: Grab the original message  that was reported (using smart headers, attachments, or references) Group messages  from the same attack together Skip duplicates  so your team isn’t doing the same thing twice It’s like a smart inbox that’s built for security teams. And yes—you can use a user mailbox , a distribution list , or a Google Group . Just make sure at least one subscriber gets all the mail. 📝 Audit Logs – Because Receipts Matter Need to know who did what and when? Sublime’s Audit Log  keeps track of: Message actions Rule changes Logins Pretty much everything Perfect for compliance or when someone swears “they didn’t touch it.” ✉️ Adding Message Sources You can connect Sublime to: Microsoft 365 Google Workspace IMAP accounts Each source gives Sublime access to ingest messages from your environment. 👉 Here’s how to add message sources 📫 Mailboxes Tab This one’s simple: it lists all mailboxes  connected to your Sublime environment—so you always know what you’re monitoring. ------------------------------------------------------------------------------------- 🎯 Final Thoughts ASA is like that one intern who learns fast, works 24/7, and doesn’t need supervision. Whether you want full control or full automation, ASA can slot into your team and start saving time and catching threats instantly . It’s where you lay the foundation—so the cool stuff (like ASA) can do its thing without chaos. And there you go. That’s Sublime Security’s Admin tab , decoded in plain English. -----------------------------------Dean------------------------------------------- Upcoming Article: (Last Article): The Final Piece: Hunting, Searching, and Analyzing Like a Pro in Sublime EDR for Email https://www.cyberengage.org/post/the-final-piece-hunting-searching-and-analyzing-like-a-pro-in-sublime-edr-for-email -------------------------------------------------------------------------------------